On Mon, 22 Nov 1999 02:45:52 +0100 Stefan Rieken <StefanRieken at SoftHome.net> wrote:
>Luckily my ignorance has also been the occasion for thoughts on
>"overviewing Squeak". I guess that what Marcus calls relationship, the
>OO bookstore calls "aggregation". Objects are being aggregated by having
>other objects as their instance variables, e.g. a window has an related
>rectangle etc. (right?). Morphs have submorhps to solve this.

Right. I would be painfully difficult to try to create something like a browser out of a *single* object and it would yield code with very low reusability. As it is, complex things can (fairly) easily be built by aggregataing several somewhat less complex objects: list panes, text panes, buttons, etc.

[snip]

>This Object Inspector should show any selected object _complete_,
>without bothering the technical constructs of inheritance and classes.
>But including all its methods and aggregations (instance variables),
>also those that it had inherited off course. This should also
>(particularly?) be useable for overviews of Morphs.
>
>The current tiling system does try to show a Morph. My problem with it
>is that it doesn't show a Morph _complete_, like in a class browser
>combined with an object explorer. But it could possibly be extended to
>suit this. The other possibility would be to extend the object explorer
>to also display the object's methods.

The obvious challenge here is how to show *everything* and at the same time make the inspector easy to use.

>Hope this is useful to some of you.

Sure. It suggests possibilities of a unified view (I was thinking earlier today about a Grand Unified Explorer). And it points out things that need perhaps a little more advertising. There are a tremendous number of tools/capabilities inside Squeak and one goal is to organize them in a more accessible and understandable way.

>Greets,
>
>Stefan
>
>(one P.S.: how come the "explore" method can show an object's instance
>variables? I thought they were private to the object?)

That's one of the asterisks beside the notion of encapsulation being complete in Smalltalk. There are methods (intended for debuggers and the like) that can directly access another. Not what you want to use in normal programming, but invaluable at times, especially when something breaks. If you are interested, check out Object>>instVarAt:.

Cheers,
Bob