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+dl...@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