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

[Martin <eden_martin_fuhrspam@...>]

(I have troubles with my email client, so quoting manually.)

Dirk Laurie:
> 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
breaking changes.

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).
]]

-- Martin