On Wednesday, 19 September 2018 at 06:11:22 UTC, Vladimir
Panteleev wrote:
On Wednesday, 19 September 2018 at 06:05:38 UTC, Vladimir
Panteleev wrote:
[...]
One more thing:
There is the argument that the expected behavior of Phobos
functions creating filesystems objects with long paths is to
succeed and create those files. However, this results in
filesystem objects that most software will fail to access
(everyone needs to also use the long paths workaround).
One point of view is that the expected behavior is that the
functions succeed. Another point of view is that Phobos should
not allow programs to create files and directories with invalid
paths. Consider, e.g. that a user writes a program that creates
a large tree of deeply nested filesystem objects. When they are
done and wish to delete them, their file manager fails and
displays an error. The user's conclusion? D sucks because it
corrupts the filesystem and creates objects they can't operate
with.
I was wanting to reply with something similar:)
My 2 cents..whatever it's worth. Vladimir has expressed most if
not all the points I would have brought up. Abscissa did bring
up a good idea to help users support long filenames, but I agree
with Vladimir that this should be "opt-in". Provide a function
in phobos for it, plus, it lets them cache the result AND
infinitely better, the developer knows what's going on. What
drives me mad is when you have library writers who try to
"protect" you from the underlying system by translating
everything you do into what they "think" you're trying to do.
This will inevitably result in large complex adaptation layers as
both the underlying system and the front-facing API change over
time with unwieldy maintenance burden. An opt-in solution
doesn't have this problem because you've kept each solution
orthogonal rather than developing a translation layer that needs
to be able to determine what the underlying system does or does
not support. This is a fundamental example of encapsulation, the
filesystem library should be it's own component with the windows
filesystem workaround being an optional "add-on" that the
filesystem library doesn't need to know about. This workaround
could look like an extra function in phobos...or you could even
write a module that wraps std.file and does the translation on a
per-call basis.