Proposal for std.path replacement

[spir]

On 03/06/2011 10:49 PM, Nick Sabalausky wrote:
> "Lars T. Kyllingstad"<public at kyllingen.NOSPAMnet>  wrote in message
> news:il09fp$2h5d$1 at 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