On 2010/09/02 12:45, Bert Freudenberg wrote:
>
> On 02.09.2010, at 11:05, Frank Shearar wrote:
>
>> On 2010/09/02 02:57, Andreas Raab wrote:
>>> On 9/1/2010 1:49 PM, Bert Freudenberg wrote:
>>>> On 01.09.2010, at 22:22, Frank Shearar wrote:
>>>>
>>>>> On 2010/09/01 15:38, Bert Freudenberg wrote:
>>>>>> On 01.09.2010, at 10:25, Frank Shearar wrote:
>>>>>>
>>>>>>> On 2010/09/01 07:32, commits at source.squeak.org wrote:
>>>>>>>> Andreas Raab uploaded a new version of Network to project The Trunk:
>>>>>>>> http://source.squeak.org/trunk/Network-ar.82.mcz
>>>>>>>>
>>>>>>>> ==================== Summary ====================
>>>>>>>>
>>>>>>>> Name: Network-ar.82
>>>>>>>> Author: ar
>>>>>>>> Time: 1 September 2010, 12:32:08.542 am
>>>>>>>> UUID: aa52635f-d746-5744-b432-582c5ba62b11
>>>>>>>> Ancestors: Network-ul.81
>>>>>>>>
>>>>>>>> Use HttpUrl when dealing with https, i.e.,
>>>>>>>> 'https://encrypted.google.com' asUrl class == HttpUrl
>>>>>>>>
>>>>>>>> =============== Diff against Network-ul.81 ===============
>>>>>>>>
>>>>>>>> Item was changed:
>>>>>>>> ----- Method: Url class>>urlClassForScheme: (in category
>>>>>>>> 'parsing') -----
>>>>>>>> urlClassForScheme: scheme
>>>>>>>> (scheme isNil or: [scheme = 'http']) ifTrue: [^HttpUrl].
>>>>>>>> + scheme = 'https' ifTrue: [^HttpUrl].
>>>>>>>> scheme = 'ftp' ifTrue: [^FtpUrl].
>>>>>>>> scheme = 'file' ifTrue: [^FileUrl].
>>>>>>>> scheme = 'mailto' ifTrue: [^MailtoUrl].
>>>>>>>> scheme = 'browser' ifTrue: [^BrowserUrl].
>>>>>>>> ^GenericUrl!
>>>>>>>
>>>>>>> That reminds me: for my SipStack I would need to touch this method
>>>>>>> (*), as would any other packages using other kinds of URLs.
>>>>>>>
>>>>>>> Perhaps we need a registry-based approach, so that we can safely
>>>>>>> load multiple URL-defining packages?
>>>>>>>
>>>>>>> I see no point in having SipUrl become part of Network, because
>>>>>>> most images won't use it. Protocols like HTTP and FTP are pretty
>>>>>>> much ubiquitous on the other hand, so it makes sense to keep them
>>>>>>> in Network(-Url).
>>>>>>>
>>>>>>> frank
>>>>>>
>>>>>> The canonical way would be to iterate through Url subclasses in
>>>>>> reverse superclass-order to find the most specialized subclass
>>>>>> willing to handle a particular scheme.
>>>>>
>>>>> OK, I hope my attempt's reasonable. Each subclass says what schemes
>>>>> it handles in Foo class>>handlesScheme:. Url
>>>>> class>>urlClassForScheme: finds the most specific subclass that will
>>>>> accept a particular scheme, by finding the first to say "yes please"
>>>>> in Url allSubclasses reverse.
>>>>>
>>>>> The package number's not great though: it should be Network-fbs.83,
>>>>> adding to Network-ar.82.
>>>>>
>>>>> frank
>>>>
>>>> Code looks good. But lets hear from people more familiar with the
>>>> Network package or URLs if this is the way it should be ...
>>>
>>> The code looks okay to me, albeit maybe adding a little more complexity
>>> than strictly necessary. I think I would prefer a registration mechanism
>>> (simple map of scheme to url class) over the classes queries because
>>> there can be situations where you'd like to register schemes with
>>> existing URL classes and I find it simpler to say (for example)
>>>
>>> RTSPClient class>>initialize
>>> "Make sure that rtsp URLs can be handled"
>>>
>>> Url registerUrlClass: HierarchicalUrl forScheme: 'rtsp'.
>>>
>>> SqueakSSL class>>initialize
>>> "Make sure a suitable URL class is registered for https"
>>>
>>> (Url urlClassForScheme: 'https') == GenericUrl ifTrue:[
>>> "No good; re-register as HttpUrl"
>>> Url registerUrlClass: HttpUrl forScheme: 'https'.
>>> ].
>>>
>>>
>>> instead of having to subclass and implementing #handlesScheme:. But this
>>> may be just me :-)
>>
>> I'm happy either way: I just want a way to hook schemes to classes without stomping on other packages. My first thought was to have a registry (I like decoupling the class-finding from the inheritance tree), and then Bert reckoned the canonical way would be to ask the subclasses.
>>
>> Network-fbs.85 in the inbox implements a registry-based approach.
>>
>> frank
>
> Yep, that's more flexible. And more efficient too. Win-win.
>
> However, the registry should be a class variable not class inst variable IMHO.

Network-fbs.86 does this.

I'm not entirely sure what the difference is between a class variable 
and a class inst variable. I understand that the latter is an instance 
variable of the object "Foo class", but what's the practical difference 
between the two? When do you, or should you, use a class inst variable, 
and when not?

frank