[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Proposal: package.(c)path as tables
- From: Martin <eden_martin_fuhrspam@...>
- Date: Thu, 7 Sep 2017 11:46:42 +0100
(I have troubles with my email client, so quoting manually.)
> You miss a most compelling third: it is a breaking change. It will
> affect all programs that currently modify/change package.path.
> For a breaking change, arguments of like "elegant", "more
> understandable", "easier to manipulate" are not strong enough,
> especially when a simple workaraound is available.
There is simple workaround for this too:
v5.5 Introduce "package.path_t", "package.cpath_t".
Declare "package.path", "package.cpath" deprecated.
v6.0 Drop "package.path", "package.cpath"
will be enough. After it we'll get ugly names but code will look
better anyway (IMO).
Dropping "module()", "package.seeall()", moving "unpack()" - that was
So there are precedents and a way to implement proposal without
instant hurting code at next version.
I see a better way to manage list of directories. But don't consider
this as argument versus proposal.
Anyway even if it will be implemented it's not the final answer.
In v6.1 someone will note that there is no duplicates checking and
he must write "for" loop before table insert.
What is really needed (IMO) is set-like data structure with
two core operations: add, remove.
(table: key - path (string), value - true).