What is the rationale behind std.file.setAttributes ?

[Marco Leise]

Am Fri, 27 Dec 2013 09:04:39 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> I picture two ways out of this:
> 
> 1. Improve the DirEntry abstraction by e.g. allowing it to fetch 
> attributes only etc.
> 
> 2. Define a ligthly structure FileAttributes structure that encapsulates 
> the integral and offers portable queries such as isDir, isFile etc.
> 
> Any takers?

Wait a second, what about *setting* attributes? Some difficult
ones are:

o toggling read-only (for whom? user, group, others?)
o executable flag
o hidden flag

On Windows 'executable' is implicit and based on the extension.
On Posix 'hidden' is implicit for a file name beginning with a
dot. We can read the hidden bit on POSIX, but we cannot toggle
it for example. So we can either not expose these attributes
at all, ignore them where not applicable when setting
attributes or add a third state "ignore".

Or looking at it another way:
DOS attr < POSIX chmod < ACLs

How do other programming languages find a common ground?
Should Phobos add file attributes on a case by case basis?
E.g. Someone needs to toggle read-only, so we think about how
we handle that on POSIX and decide that when a file is made
writable we set the writable bits according to umask.
(http://en.wikipedia.org/wiki/Umask)
These properties can extend a DirEntry, but it is somewhat
limiting without free functions to supplement it.

> As a general note, we are suffering from an deflation of reviewers 
> compared to contributors. I've looked at Phobos closely again in the 
> past couple of weeks and saw quite a few things in there that I wouldn't 
> have approved. On the other hand, nobody can be expected to babysit 
> Phobos 24/7 so the right response would be closer scrutiny of pull 
> requests by the entire community. To foster that, one possibility would 
> be to automatically post new pull requests to this group. What do you 
> all think?

Actually I'm opposed to this. It creates noise (especially if
dmd/druntime changes are included that only a hand full of
people understand) and GitHub already offers this
functionality in the form of notifications.

"Notifications are based on the repositories you are watching.
 If you are watching a repository, you will receive notifications
 for all discussions, including:

 o Issues and their comments
 o Pull Requests and their comments
 o Comments on any commits"

It is very coarse though, so unless GitHub is open to limiting
notifications to pull requests only, it could still be useful
to post pull requests to this list.
 
> Thanks,
> 
> Andrei

-- 
Marco