What is the rationale behind std.file.setAttributes ?

[Marco Leise]

On Saturday, 28 December 2013 at 08:18:44 UTC, Jonathan M Davis 
wrote:
> on it specifically. My main point was that some stuff in 
> std.file is system-
> specific and that if it has to be, it's better to have it in 
> std.file as system-
> specific rather than not having it at all just because it 
> couldn't be
> completely cross-platform and portable. So, just because 
> setFileAttributes is
> doing something system-specific does not mean that it's bad.

Agreed. And really I didn't want to make a point about how it
should be done right when I started this thread. This
particular function just seemed not in line with Phobos
principles as I remember them. :)

Am Sat, 28 Dec 2013 09:02:01 +0000
schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang at gmail.com>:
> It is bad. If you want system-specific behaviour you should have 
> a separate interface that provide all the advantages that going 
> to a lower level provides. Having half-assed OS-specific support 
> is too pragmatic and will lead to a legacy mess in the long run 
> when those interfaces become obsolete.
> 
> A good file abstraction should also support newer file systems 
> like Google Cloud Storage, though. GCS does not support append() 
> or directories.
> 
> A good file abstraction should also provide mechanisms to deal 
> with different levels of consistency on the underlying filesystem 
> and caching-mechanism:
> - read after write might return an old version
> - read after write returns the new version if read from the same 
> computer
> - read after write always returns the new version
> 
> As a new language D should support Cloud based environments 
> out-of-the-box with a hierarchy of functionality down to the 
> peculiarities of Windows/Posix etc so that you can decide to code 
> in a manner that supports all platforms without having to litter 
> your code with ifs and version-statements… and also restrict you 
> to the subset you have "authorized" so that you can develop on 
> your Windows system and port it to the cloud with just a 
> recompile without knowing the details of the cloud file system. 
> (i.e. the compiler warns you when you are using system specific 
> functionality).
> 
> I also think good file system support implies built-in caching 
> and let the library decide whether to turn library-level caching 
> on or off based on what the operating system or underlying 
> interface supports. E.g. the ability to tell the system that you 
> want successive reads of a file to be available fast at the cost 
> of consistency.

Are you hijacking this thread to ask for Google Cloud
support? ;) Don't forget FTP, SSH, WebDAV, ...
Implementing all of this can take quite some time and will
result in something like the "Gnome virtual file-system". It
might become so large that std.file is easily reimplemented as
a tiny part of it for the native file-system module.

Basic OS level file-system I/O support is useful on its own,
especially in a systems programming language. You don't need
to pull in a whole bunch of dependencies to read a text file.

-- 
Marco