Re: Proposal: package.(c)path as tables

["szbnwer@..." <szbnwer@...>]

hi there all :)

personally i like this proposal, and mostly what i wanted to say about
it has been already said, but here is all of it:

so my idea to chance is to bump version, so who will make
compatibility for their stuffs, that will be straightforward. the
remaining old and unmaintained(?) packages can still have a simple
compatibility module, that can be like a metatable for set/get both
the string and table version, and synch them. this way we can use a
'wrapper' or whatever for old stuffs, so there's no need to mess with
the contents. in the meantime we can move forward to something that is
in bigger harmony with lua, as it's kinda all around about tables; and
there's no need to a next modification, but only a cleanup for
official support for string path, while there can be a simple
workaround for keep compatibility in pure lua.

the synch and workaround wouldn't be a performance issue, for the most
of the existing packages, because it's not a heavily used stuff, but
it's more likely a lilbit of additional warmup time only.

the _t suffix is bad, because future dirt, the 'paths' can be good,
but an another guess is lookup and lookup_c or whatever, there can be
always a new name, that is not like A -> A and A+suffix -> A+suffix -
and now a 4th version to remove the unnecessary suffix, and get an
another compatibility issue for those who relied on the suffix
version...

a deprecated note is enough for the time of coexists, so a 6.1 can get
rid of all the mess.

duplications won't make harm, so that can be left for the devs, and
they will have dreamless nights if they will dare to make mess around,
but things will work...

i think it can be a good improvement and the switch can be smooth,
just think out well the rest of the fate of the contents of package to
make something that can have a long life as is...

so +1, and i think it wouldn't be a big pain from any side