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.
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 <sean@clipperadams.com> 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.
Sven Van Caekenberghe-2 wrote
Having subclasses for each scheme is hard to maintain (there are hundreds of schemes)... It also makes little sense implementation wise.
Iâm not understanding. For one thing, in Core, weâre not interested in all of the hundreds of schemes but just the few most common (http, file) - although users interested in the specifics of other schemes could easily add those subclasses in their apps. Since subclassing is just a way to share code, wouldnât a ZnFileUrl merely consist of exactly the methods weâre talking about - but more simply implemented? For one thing, it seems it would make extension easier. If I wanted to handle FileUrls and HttpUrls polymorphically with separate classes, no problem - implement two methods. But as it is now, IIUC I have to either implement two operation classes or have a method with a budding switch statement. Also, IMHO implementing a custom multiple dispatch seems exotic enough (i.e. takes extra effort to understand) to require a large benefit to justify. My 2c ----- Cheers, Sean -- View this message in context: http://forum.world.st/FileUrl-Removal-Rationale-tp4816536p4817064.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Am 02.04.2015 um 23:55 schrieb Sean P. DeNigris <sean@clipperadams.com>:
Sven Van Caekenberghe-2 wrote
Having subclasses for each scheme is hard to maintain (there are hundreds of schemes)... It also makes little sense implementation wise.
Iâm not understanding. For one thing, in Core, weâre not interested in all of the hundreds of schemes but just the few most common (http, file) - although users interested in the specifics of other schemes could easily add those subclasses in their apps. Since subclassing is just a way to share code, wouldnât a ZnFileUrl merely consist of exactly the methods weâre talking about - but more simply implemented? For one thing, it seems it would make extension easier. If I wanted to handle FileUrls and HttpUrls polymorphically with separate classes, no problem - implement two methods. But as it is now, IIUC I have to either implement two operation classes or have a method with a budding switch statement. Also, IMHO implementing a custom multiple dispatch seems exotic enough (i.e. takes extra effort to understand) to require a large benefit to justify.
I think the problem is that URI structure/format and interpretation are mixed together generating that problem. Sven is right about not having additional classes for URIs. An URI is an URI regardless how it looks like foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose The authority is optional, so URI wise there is no difference between a file URI and another one. The difference is in the interpretation of them. The interpreting part (the handler) is selected by the scheme. Having scheme as a registry would enable one to register his own handler for dealing with certain schemes. The downside is that dealing with URIs would be harder because you would need to use an extra selector between all calls that does the dispatch over the handler. A anZnUrl handler asFileReference This way there would be a FileHandler that implements #asFileReference. Other handlers might give a DNU. I understand the wish to keep the usage of ZnUrl simple not having to use extra selectors. But that wish turns out to be the problem IMHO and subclassing ZnUrl is not a cure for it just a way to make it worse. my 2 cents, Norbert
participants (3)
-
Norbert Hartl -
Sean P. DeNigris -
Sven Van Caekenberghe