`package.path_t` etc. is actually quite similar to something I've done with FusionScript. I made it so FusionScript's package loader has a `package.fusepath_t` - however, I didn't make a `package.fusepath` because that would mean similarities with the other `package.c?path` variables. :+1: for `package.c?path_t`, but I'm not sure how that would work while still having a `package.path` - perhaps a special __index function that "renders" it based on the `_t` version?.
On 09/06/2017 12:32 PM, Dirk Laurie wrote:
> 2017-09-06 10:26 GMT+02:00 Daurnimator <quae@daurnimator.com>:
>> At the moment, package.path and package.cpath are strings containing
>> semicolon separated lists.
>> I'd like to propose that they are transitioned to be sequences to
>> allow for easier programmatic manipulation.
>
> local path = {}
> package.path:gsub("[^;]*,function(x) path[#path+1]=x end
>
> A breaking change to save having to code that? DMML
>
String format for <package.path> looks like fossil from early versions.
To get terms (for example, when searching module "by hands") we have to
implement our own parsing functions.
So I am completely agree with proposal.
If this change breaks existing code - new config tables may be named
like "package.path_t" and "package.cpath_t".
--[[
Also there is weird stuff in <package.config>. (String which must
contain five lines with special meaning.) I'd like to change it too.
]]
-- Martin
