On 03/06/2011 10:49 PM, Nick Sabalausky wrote:
"Lars T. Kyllingstad"<public@kyllingen.NOSPAMnet> wrote in message
news:il09fp$2h5d$1...@digitalmars.com...
On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote:
What about extending the notion of 'device' (see other post) to cover
'http://' and "ftp://";?
Would it be complicated?
I don't think std.path should handle general URIs. It should only have
to deal with the kind of paths you can pass to the functions in std.file
and std.stdio.
If std.path doesn't handle uri's, then we'd need a whole other set of
functions for dealing with uris. And at least a few of the functions would
overlap. And then people who want to be able to handle both files and uris
will want functions that will seamlessly handle either. So I think it really
would be best to just bite the bullet and have std.path handle uri's.
That said, I'm not sure this would be necessary for round 1 of the new
std.path. Could just be added later.
Right, but if there is reasonable probability for such an extension, then we
must think at it, so-to-say "at design time". Else, various common issues will
raise barriers on the way of extension (existing codebase, detail conflicts,
refactoring requirements... naming! ;-) (*)
Then, once such work is on good way, possibly implementation is no more such a
big deal. Or, conversely, we may feel the need for prototyping and trials to
construct and/or validate a big picture design. Etc...
To sum up: since there is no emergency (--> Andrei's last post), we have a very
good base thank to Lars's well-thought job, and there are already a number of
people involved in the discussion -- why not?
Denis
(*) drive name --> ?
--
_________________
vita es estrany
spir.wikidot.com
