Quoting Frank Shearar <[hidden email]>: > On 2011/01/02 11:13, Levente Uzonyi wrote: >> On Fri, 31 Dec 2010, Frank Shearar wrote: >> >>> On 2010/12/31 16:12, Levente Uzonyi wrote: >>>> On Fri, 31 Dec 2010, Frank Shearar wrote: >>>> >>>>> On 2010/12/31 13:59, Enrico Spinielli wrote: >>>>>> Hi, >>>>>> I still have the following applied in my image and I see it is still >>>>>> not yet in Trunk. >>>>>> Any core developer willing to commit it? >>>>> >>>>> It's not in the Inbox anymore and you're right, it wasn't applied. I >>>>> have a local copy I can put back in the Inbox, if it's convenient? Or >>>>> if preferred I can remake the submission based on Network's latest >>>>> version. >>>> >>>> I moved it to the treated inbox, because another solution was applied. >>>> SchemeRegistry has HttpUrl at nil, so Url urlClassForScheme: nil should >>>> return HttpUrl. >>> >>> Right, I see so. My confusion in reconstructing history came from >>> Andreas suggesting the fix I implemented in Network-fbs.91, after >>> suggesting we either fix the call sites causing the issue or what you >>> then did on 2010/10/28, Levente, and then not seeing anything happen >>> after that (in my possibly too-brief investigation). >>> >>> (Why, by the way, do we _not_ call super initialize?) >> >>> From which method? > > Url class>>initialize. In a git-like diff we have > > +++ SchemeRegistry := Dictionary new > --- super initialize. > --- SchemeRegistry := Dictionary new. > --- SchemeRegistry > at: 'browser' put: BrowserUrl; > at: 'file' put: FileUrl; > at: 'ftp' put: FtpUrl; > at: 'http' put: HttpUrl; > at: 'https' put: HttpUrl; > at: 'mailto' put: MailtoUrl; > at: nil put: HttpUrl; > yourself > --- at: 'mailto' put: MailtoUrl. There are a few reasons why we shouldn't send #initialize to super from the class side. In this case it doesn't make a real difference, because Url is a subclass of Object, and Object implements #initialize on the class side relatively safely. What are the problems with the super sends? - if your class is not a subclass of Object, but ProtoObject, then sending #initialize to super will mess up your class, because you will execute Behavior >> #initialize. - a superclass may initialize class variables which are shared by it's subclasses, doing that from the subclasses may break some stuff. Levente > > frank >> >> >> Levente >> >>> >>> frank >>>> >>>> >>>> Levente >>>> >>>>> >>>>> frank >>>>> >>>>>> >>>>>> Hope it helps >>>>>> Bye >>>>>> Enrico >>>>>> >>>>>> On Wed, Sep 8, 2010 at 08:31, Frank Shearar >>>>>> <[hidden email]> wrote: >>>>>>> On 2010/09/08 08:04, Andreas Raab wrote: >>>>>>>> >>>>>>>> On 9/7/2010 11:01 PM, Frank Shearar wrote: >>>>>>>>> >>>>>>>>> There's a quicker test: Do It with: Url absoluteFromText: 'foo' >>>>>>>>> >>>>>>>>> Up until my submission (which is causing this trouble), "no scheme" >>>>>>>>> meant "use an HttpUrl". >>>>>>>>> >>>>>>>>> I can see two ways forward: (a) fix the calling sites like C. A. >>>>>>>>> Oliver's submission, or (b) add "at: nil put: HttpUrl" in the >>>>>>>>> SchemeRegistry. >>>>>>>>> >>>>>>>>> I prefer (a) myself: 'foo' isn't any kind of valid _absolute_ URI. >>>>>>>>> >>>>>>>>> The Inbox contains Network-fbs.90, which contains (b)'s fix. >>>>>>>> >>>>>>>> Perhaps even easier: >>>>>>>> >>>>>>>> ^SchemeRegistry at: (scheme ifNil:['http']) ifAbsent:[GenericUrl] >>>>>>> >>>>>>> I prefer this to my submission: it doesn't pollute SchemeRegistry. >>>>>>> >>>>>>> Network-fbs.91 contains it. >>>>>>> >>>>>>> frank >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > |
On 2011/01/11 01:40, Levente Uzonyi wrote:
> > > Quoting Frank Shearar <[hidden email]>: > >> On 2011/01/02 11:13, Levente Uzonyi wrote: >>> On Fri, 31 Dec 2010, Frank Shearar wrote: >>> >>>> On 2010/12/31 16:12, Levente Uzonyi wrote: >>>>> On Fri, 31 Dec 2010, Frank Shearar wrote: >>>>> >>>>>> On 2010/12/31 13:59, Enrico Spinielli wrote: >>>>>>> Hi, >>>>>>> I still have the following applied in my image and I see it is still >>>>>>> not yet in Trunk. >>>>>>> Any core developer willing to commit it? >>>>>> >>>>>> It's not in the Inbox anymore and you're right, it wasn't applied. I >>>>>> have a local copy I can put back in the Inbox, if it's convenient? Or >>>>>> if preferred I can remake the submission based on Network's latest >>>>>> version. >>>>> >>>>> I moved it to the treated inbox, because another solution was applied. >>>>> SchemeRegistry has HttpUrl at nil, so Url urlClassForScheme: nil >>>>> should >>>>> return HttpUrl. >>>> >>>> Right, I see so. My confusion in reconstructing history came from >>>> Andreas suggesting the fix I implemented in Network-fbs.91, after >>>> suggesting we either fix the call sites causing the issue or what you >>>> then did on 2010/10/28, Levente, and then not seeing anything happen >>>> after that (in my possibly too-brief investigation). >>>> >>>> (Why, by the way, do we _not_ call super initialize?) >>> >>>> From which method? >> >> Url class>>initialize. In a git-like diff we have >> >> +++ SchemeRegistry := Dictionary new >> --- super initialize. >> --- SchemeRegistry := Dictionary new. >> --- SchemeRegistry >> at: 'browser' put: BrowserUrl; >> at: 'file' put: FileUrl; >> at: 'ftp' put: FtpUrl; >> at: 'http' put: HttpUrl; >> at: 'https' put: HttpUrl; >> at: 'mailto' put: MailtoUrl; >> at: nil put: HttpUrl; >> yourself >> --- at: 'mailto' put: MailtoUrl. > > There are a few reasons why we shouldn't send #initialize to super from > the class side. In this case it doesn't make a real difference, because > Url is a subclass of Object, and Object implements #initialize on the > class side relatively safely. What are the problems with the super sends? > - if your class is not a subclass of Object, but ProtoObject, then > sending #initialize to super will mess up your class, because you will > execute Behavior >> #initialize. > - a superclass may initialize class variables which are shared by it's > subclasses, doing that from the subclasses may break some stuff. Right. The subclass can re-initialise all those variables that contain things the superclass needs. Classes are also long-lived objects, and might contain state gathered over time. That means that if one wants to protect one's class against subclasses doing a super-send of #initialize one ought to lazily initialise one's class instance variables, right? (I hope I got the terminology right there: instance variables of the class.) Like so: MyVar := MyVar ifNil: [MyVar := MyVar new] Maybe we ought to put a warning in Behavior>>initialize then? Something like what we do with Undeclared: Transcript showln: 'Class ', self className, ' should not call Behavior>>initialize.'. frank > Levente > >> >> frank >>> >>> >>> Levente >>> >>>> >>>> frank >>>>> >>>>> >>>>> Levente >>>>> >>>>>> >>>>>> frank >>>>>> >>>>>>> >>>>>>> Hope it helps >>>>>>> Bye >>>>>>> Enrico >>>>>>> >>>>>>> On Wed, Sep 8, 2010 at 08:31, Frank Shearar >>>>>>> <[hidden email]> wrote: >>>>>>>> On 2010/09/08 08:04, Andreas Raab wrote: >>>>>>>>> >>>>>>>>> On 9/7/2010 11:01 PM, Frank Shearar wrote: >>>>>>>>>> >>>>>>>>>> There's a quicker test: Do It with: Url absoluteFromText: 'foo' >>>>>>>>>> >>>>>>>>>> Up until my submission (which is causing this trouble), "no >>>>>>>>>> scheme" >>>>>>>>>> meant "use an HttpUrl". >>>>>>>>>> >>>>>>>>>> I can see two ways forward: (a) fix the calling sites like C. A. >>>>>>>>>> Oliver's submission, or (b) add "at: nil put: HttpUrl" in the >>>>>>>>>> SchemeRegistry. >>>>>>>>>> >>>>>>>>>> I prefer (a) myself: 'foo' isn't any kind of valid _absolute_ >>>>>>>>>> URI. >>>>>>>>>> >>>>>>>>>> The Inbox contains Network-fbs.90, which contains (b)'s fix. >>>>>>>>> >>>>>>>>> Perhaps even easier: >>>>>>>>> >>>>>>>>> ^SchemeRegistry at: (scheme ifNil:['http']) ifAbsent:[GenericUrl] >>>>>>>> >>>>>>>> I prefer this to my submission: it doesn't pollute SchemeRegistry. >>>>>>>> >>>>>>>> Network-fbs.91 contains it. >>>>>>>> >>>>>>>> frank >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > > > > |
Free forum by Nabble | Edit this page |