Hi Sean, You are right that ZnUrl unifies all schemes in one object class.
Something called ZnUrlOperation exists and is used to dispatch named operations on multiple conditions, the scheme, some arguments, but potentially any aspect of a URL. Having subclasses for each scheme is hard to maintain (there are hundreds of schemes) and is only one dimension of looking at URLs. It also makes little sense implementation wise. The #asFileReference implementation does indeed have a hard test inside it, but it is in essence correct: you can only do the conversion is that particular case. I am not saying that the way things are today is the final answer to URL implementation, maybe things can be improved. But what we have now covers a lot of ground (usage scenarios). BTW, Xtreams' #reading, #writing & #appending could also make sense for non-file URLs ... Sven > On 01 Apr 2015, at 04:19, Sean P. DeNigris <[email protected]> wrote: > > I guess FileUrl has been subsumed by ZnUrl. The problem is that the fact that > a URL points to a file is part of it's type. Now there is the ugly: > ZnUrl>>#asFileReference > ... > self assert: self scheme = #file description: 'Only a file:// URL can be > converted to a FileReference'. > > Also Xtreams had FileUrl #reading, #writing, #appending, which also don't > make sense in their current implementations for non-file URLs. > > Suggestions? Comments? > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/FileUrl-Removal-Rationale-tp4816536.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
