ResourceBrowser sortBlock

Can someone explain the sortBlock in column 3 ("Package") of the
ResourceBrowser.  It is:

    ([:a :b | a name < b name]) receiver: nil; yourself

The getContentsBlock is "Message selector: #owningPackage", so a and b
should each be a Package or nil.  Package>>name and UndefinedObject>>name
both return strings, in which case

    [:a :b | a name < b name]

should work fine.  (BTW, it's clever that UndefinedObject has a method,
#name, that returns the string 'nil'.)

I'm curious if the "receiver: nil; yourself" portion of this sortBlock is
superfluous?  If not, why not?  If yes, what was the intent, or put another
way, is there a case where this type of thing would be used?

-- Louis

Louis,

>     ([:a :b | a name < b name]) receiver: nil; yourself
[..]
> I'm curious if the "receiver: nil; yourself" portion of this sortBlock is
> superfluous?  If not, why not?  If yes, what was the intent, or put
> another way, is there a case where this type of thing would be used?

I'm just guessing but isn't this just another way of getting round the
"retained reference to the compilation context in a SortedCollection's
sortBlock" problem referred to in the WIKI page

http://www.object-arts.com/wiki/html/Dolphin/ListPresentersAndSorting.htm

The problem there, IIRC, was that the BlockClosure retains a reference to
the context  it was compiled in (so that #self works). Going through a
Binary save/load loses and recreates the original context so the
SortedCollection's sortBlock is left referring to an unavailable object.
Setting the receiver to nil will remove this dependency on a particular
context and let the ListView that includes the sortBlock be passed in a
binary resource.

Having said that, after a peek in the image I think there may be a bit more
too it (or I'm on completely the wrong track of course <g>). Have a look at
the first two columns in the "MethodBrowser.Class method browser list"
resource. The first leaves the block's receiver alone but the second sets it
to nil? They look pretty similar in what they do though so why the
difference?

Regards
    Ian

Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:8LWX7.5152$XN3.282104@wards...
> Louis,
>
> >     ([:a :b | a name < b name]) receiver: nil; yourself
> [..]
> > I'm curious if the "receiver: nil; yourself" portion of this sortBlock
is
> > superfluous?  If not, why not?  If yes, what was the intent, or put
> > another way, is there a case where this type of thing would be used?
>
> I'm just guessing but isn't this just another way of getting round the
> "retained reference to the compilation context in a SortedCollection's
> sortBlock" problem referred to in the WIKI page

It was, but this was fixed in 4.0 or a subsequent revision. I'm not sure
exactly when, as it predates our current bugs database. The particular
resource just happens to have an old workaround in it. The "bug fix" can be
seen in Aspect class>>block:.

Regards

Blair

Ian and Blair,

Thanks for the explanations.  I understand from a high-level, but I still
don't follow the syntax et al, certainly not enough to use the new
workaround (as seen in Aspect class>>block:  And that's ok, I'm not in a
rush to use it.).  Perhaps this is an instance where my self is holding on
to a MentalBlock. *g*

-- Louis

P.S.  As far as I can see, the workaround mentioned on the Wiki page is
still needed, so I'm reading Blair's "this was fixed in 4.0 or a subsequent
revision" as meaning a new workaround was introduced (e.g., in Aspect),
though not actually implemented in SortedCollection.

Louis,

> Thanks for the explanations.  I understand from a high-level, but I still
> don't follow the syntax et al, certainly not enough to use the new
> workaround (as seen in Aspect class>>block:  And that's ok, I'm not in a
> rush to use it.).  Perhaps this is an instance where my self is holding on
> to a MentalBlock. *g*

Not just you. It's just one of those things, like Classes being instances of
Classes, that you think you understand - until the next time you have to
think about it in any depth <g>

> P.S.  As far as I can see, the workaround mentioned on the Wiki page is
> still needed, so I'm reading Blair's "this was fixed in 4.0 or a
> subsequent revision" as meaning a new workaround was introduced
> (e.g., in Aspect), though not actually implemented in SortedCollection.

Reading Blair's post, and looking at the fix, I assumed it would get around
the problem of blocks retaining a reference to their creation context - the
situation alluded to in the WIKI. However, having had a play it looks like
you are right and a 4.01.3 image still causes a walkback if you try to
save/reload a SortedCollection as part of a ListModel. It was mentioned in a
previous post that there are a number of problems that can be caused by the
retained reference and it may be that the Aspect fix solves some of them but
not others.

So yes, it looks like you still need a workaround of some sort.

Regards
    Ian