That's true.  One goal of the design was to provide access to a
first-class Theme object, without needing to either write, nor see,
that extra level of indirection in the code.

   myMorph userInterfaceTheme color

vs.

   (myMorph userInterfaceTheme propertyNamed: #color)

The latter becomes a wordy and repetitious (not to mention, the extra
parenthesis), a lot to ask clients to sprinkle throughout their code.

I don't see the example "never being GC'd" as being related to the
UserInterfaceTheme implementation.  I may be missing your question but
-- if an explorer is opened [substitute with any case of:  user still
needs the object], the object would not be GC'd, regardless from which
code it was opened.

 - Chris

On Sun, Sep 17, 2017 at 7:02 AM, Stéphane Rollandin
<lecteur at zogotounga.net> wrote:
> Nice informative post, thanks Marcel.
>
> I think I see something fragile in the implementation though: each
> #userInterfaceTheme send must absolutely be followed by another selector,
> else the relevant stacked object (in the scope inst. var. of the theme) will
> not be popped at the proper moment.
>
> In other words, a line of code as simple as
>
>         Morph new userInterfaceTheme explore
>
> may break things in potentially ugly ways; for one thing, even if further
> scope push/pop work properly, the Morph instanciated by the above code will
> never be GCed...
>
> Does that make sense?
>
>
> Stef
>