[Pharo-project] PackageOrganizer packages vs. categories

Igor Stasenko siguctua at gmail.com
Sun Jun 17 21:30:45 EDT 2012


On 18 June 2012 01:13, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
> On Sun, Jun 17, 2012 at 3:46 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> On 17 June 2012 23:17, Stéphane Ducasse <stephane.ducasse at inria.fr> 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.

>
> 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.




More information about the Pharo-dev mailing list