Re: [ANN] LuaFileSystem 1.2.1 Released (Andre Carregal)

[duck <duck@...>]

> > Anyway, I propose that `lfs.attributes(path).modes' (note the
> > new name `modes' instead of `mode') should return a table as a set:
> > {
> >         link = true,
> >         file = true,
> > }
> >
> >         What do you think?
> 
> I like the idea and would insist that the lfs.modes bitset used the
> same terminology as the current lfs.mode string.
> 
> Other than that, it would be important to map which of the lfs.modes
> would appear as lfs.mode (even if only for backward compatibility),
> since there is apparently some priorization happening, no?

Perfect. I'd suggest that "mode" return exactly what it does now, namely
the _first_ mode flag which matches. Here is the current code:

  if      ( S_ISREG(mode) )  return "file";
  else if ( S_ISDIR(mode) )  return "directory";
  else if ( S_ISLNK(mode) )  return "link";
  else if ( S_ISSOCK(mode) ) return "socket";
  else if ( S_ISFIFO(mode) ) return "named pipe";
  else if ( S_ISCHR(mode) )  return "char device";
  else if ( S_ISBLK(mode) )  return "block device";
  else                       return "other";

There is no point in changing the semantics of "mode". Indeed, it ought
not to be changed.

OTOH, "modes" should return an associative table of _all_ the above strings 
which match (except "other", of course, which would be denoted by an empty
table). 

There is no point in changing the strings used as table indices in the 
set returned by "modes", Indeed, they ought to be the same as above, for
simplicity and consistency.

Of course, the strings in "modes" could be chaged (or augmented) if it's
decided to make "modes" return a set of mode attributes with finer 
granularity. KISS says not to bother, at least right now.