On Sun, Jun 17, 2012 at 6:30 PM, Igor Stasenko <[email protected]> wrote:
> On 18 June 2012 01:13, Eliot Miranda <[email protected]> wrote: > > > > > > On Sun, Jun 17, 2012 at 3:46 PM, Igor Stasenko <[email protected]> > wrote: > >> > >> On 17 June 2012 23:17, Stéphane Ducasse <[email protected]> > wrote: > >> >> Guys, we should hack this together. > >> >> When is next sprint? :) > >> > > >> > Next friday? > >> > > >> > >> Yeah,.. > >> because i still found things which i fail to understand in > >> SystemNavigation: > >> some while ago we kind of decided that best would be to match the > >> protocol(s) of > >> CompiledMethod and RGMethodDefinition, so you can use either one or > >> another or mix of them > >> as a model for browsers/lists etc including SystemNavigation. > >> > >> But it looks like we're still not there: > >> > >> methods := Object methodDict values. > >> SystemNavigation default browseMessageList: methods name: 'Object > methods' > >> > >> fails miserably.. > >> but if i convert it to #methodReference, it works: > >> > >> methods := (Object methodDict values). > >> methods := methods collect: #methodReference. > >> SystemNavigation default browseMessageList: methods name: 'Object > methods' > >> > >> and i feel like i was fooled: we replaced one wrapper - > >> MethodDefinition (or what was that?) > >> with another with just different name. But we still cannot use > >> CompiledMethod as a model for lists > >> etc.. > >> so can someone enlighten me, what is then changed, except a name(s)? > > > > > > I did it a long time ago in VisualWorks 3.0 (IIRC). See below. > > > >> > >> I am still clueless, why system tools cannot speak directly with > >> object(s) under the question, if necessary? > > > > > > The wrapper is a pointer. If one redefines a method when recompiling > then > > the pointer refers to the current version of the method but a direct > > reference to the method answers the old version. The direct reference > > prevents the old version being garbage collected but the pointer does > not. > > For these reasons we use methodReference and not direct references. So > the > > use of pointers is necessary to make the tools work as expected. When > > methods are selected in the method list browser tools, the tools show > > current versions, not versions as of when they were opened. This is the > > same as the system browser, which holds onto class names and selectors, > not > > on class objects and method objects. > > > > By the way, in the olden days the method list browsers worked with > strings > > that looked like 'Foo selector' and 'Foo class selector:' which were > > pointers, but painful to parse to indirect to CompiledMethods. I added > > MethodReference in VisualWorks to replace these large and inflexible > strings > > with explicit pointer objects. Looks like Squeak followed suit. > > > > I know it. > But the point is, that those tools are subscribed to system changes, > and so, if listed method get changed or removed, the tool can update > it's list accordingly, > without a need to hold indirect pointer. > IIABDFI, KISS > > > > > As evidence of painful parsing here's code form the Smalltalk-80 > > MethodListBrowser: > > > > MethodListBrowser methodsFor: 'method list' > > methodName: selection > > | aStream aSymbol | > > methodName _ selection. > > selection == nil ifTrue: [selector _ nil. ^ self textMode: > > #unclassified]. > > aStream _ ReadStream on: selection. > > className _ (aStream upTo: $ ) asSymbol. > > aSymbol _ (aStream upTo: $ ) asSymbol. > > (meta _ (aSymbol == #class) & aStream atEnd not) ifTrue: > > [aSymbol _ (aStream upTo: $ ) asSymbol]. > > protocol _ self selectedClass organization categoryOfElement: > aSymbol. > > self selector: aSymbol > > > >> > >> -- > >> Best regards, > >> Igor Stasenko. > > > > -- > > best, > > Eliot > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot
