Hi Stef,

such fragility should usually be discovered quickly by the progarmmer that tries something like this. So, this is not considered an issue for bigger projects. Since Squeak is an interactive environment, the feedback loop is very short in this regard.

As for your GC concerns: Can you construct a more elaborate example? If your environment experiences a severe memory issue, you should just try to clean-up the system like in the release process:

UserInterfaceTheme cleanUp: true.

or

Smalltalk cleanUp: true.

Since the "cope" instVar is local to a specific instance of UserInterfaceTheme, programmers can easily fix any issues there. One could also add a test case for that to improve usability. :)

Best,
Marcel
Am 17.09.2017 14:04:21 schrieb Stéphane Rollandin <lecteur at zogotounga.net>:
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170918/b7356efb/attachment.html>