[Pharo-project] PackageOrganizer packages vs. categories

Eliot Miranda eliot.miranda at gmail.com
Sun Jun 17 19:13:37 EDT 2012

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.

As evidence of painful parsing here's code form the Smalltalk-80

*MethodListBrowser methodsFor: 'method list'*
*methodName: selection*
    | aStream aSymbol |
    methodName _ selection.
    selection == nil ifTrue: [selector _ nil. ^ self textMode:
    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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120617/3be67b0d/attachment.html>

More information about the Pharo-dev mailing list