<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<p>Hi rabbit,</p>
<p><br>
</p>
<p>> <span style="font-size:12pt">What does an -override category name extension do for us? If the method name is overridden, unload removes the method even if it did switch categories I believe. Or is it possible to unload a specific category and leave the
 other category present. Yet I still don’t see how that protects an overridden method.</span></p>
<div><br>
</div>
<div>And this is exactly what the -override suffix prevents. :-)</div>
<div><br>
</div>
<div>Let's try it out by example:</div>
<div><br>
</div>
<div>Create a new package, let's call it MyPackage.</div>
<div>For this package, we want to change two methods from the base system.</div>
<div>Just as an example, let's say we want to change the methods #<span>testBitmapByteAt and #<span>testWriteOn in the class <span>BitmapBugz.</span></span></span></div>
<div><span><span><span>We'll compare both types of extension methods - regular extension methods and override methods - side by side.</span></span></span></div>
<div><span><span><span>For that, shift-yellow-click #<span>testBitmapByteAt, choose "change category...", and enter a new category named "<span>*mypackage-extension".</span></span></span></span></span></div>
<div><span><span><span><span><span>Analogously, we put #<span>testWriteOn into another new category named "*mypackage-override".</span></span></span></span></span></span></div>
<div><span><span><span><span><span><span>Now we can change both methods that have been added to our package, for instance, by adding a comment "EXTENSION" to the first method and a comment "OVERRIDE" to the second method:</span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><br>
</span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><img naturalheight="463" naturalwidth="516" size="60743" id="img391619" tabindex="0" style="user-select: none;" src="cid:a674489f-5540-4b09-a671-2cc026580d3b"><br>
</span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><br>
</span></span></span></span></span></span></div>
<div><span><span><span><span><span><span>Next, go to the Monticello browser, find our package MyPackage, and unload it:</span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><br>
</span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><img naturalheight="233" naturalwidth="339" size="20377" id="img30055" tabindex="0" style="user-select: none;" src="cid:0501c835-ce63-45de-92f7-8e07b3bbe0f3"><br>
</span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><br>
</span></span></span></span></span></span></div>
<div><span><span><span><span><span><span>Finally, head back to the class that we have changed, <span>BitmapBugz.</span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span>What has happened?</span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span>The regular extension method, #<span>testBitmapByteAt, has completely disappeared; thus, its containing package, Tests, is marked as dirty.</span></span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span><span>But the extension method, #<span>testWriteOn, still exists, and it has been reverted to its original version again: it is back in the original category (tests), and it does not contain the comment "OVERRIDE"
 any longer.</span></span></span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span><span><span>Note that the prior version of the method is still available through the versions button in the system browser.</span></span></span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span><span><span><br>
</span></span></span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span><span><span>The same thing happens every time you load or unload any package that has override methods: on loading, the original methods are replaced, and on unloading, the original versions that have been remembered
 are installed again.</span></span></span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span><span><span><br>
</span></span></span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span><span><span>Note that the order of recategorizing and editing a method matters: if you first edit it (while it is still contained in the original package) and then move it to the extension category, Monticello
 will restore the wrong version of the method (including your edits) when unloading the new package.</span></span></span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span><span><span><br>
</span></span></span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span><span><span>> > </span></span></span></span></span></span></span></span></span><span style="font-size:12pt">E4. A postscript/preamble of removal uses the Compiler/ClassOrganizer to touch other packages, e.g., to
 clean up Autogenerated methods.</span><span><span><span><span><span><span><span><span><span>
<div>> </div>
</span></span></span></span></span></span></span></span></span></div>
<div><span><span><span><span><span><span><span><span><span>> </span></span></span></span></span></span></span></span></span><span style="font-size:12pt">Would it help to have a preunload and unpostscript, in the MCZ / SAR?</span><span><span><span><span><span><span><span><span><span>
<div><br>
</div>
<div>Monticello/MCZs do have four scripts for each package:</div>
<div><br>
</div>
<div><img naturalheight="166" naturalwidth="223" size="13801" id="img546478" tabindex="0" style="max-width: 99.9%; user-select: none;" src="cid:ddd315fa-b606-4e4a-8f35-5e69ad4de335"><br>
</div>
<div><br>
</div>
<div>The preamble is executed before the package is loaded.</div>
<div>The postscript is executed after the package was loaded.</div>
<div>The preambleOfRemoval is executed before the package is unloaded.</div>
<div>The postscriptOfRemoval is executed after the package is unloaded.</div>
<div>See the hierarchy of <span>MCScriptDefinition for details.</span></div>
<div><br>
</div>
<div>I think this should meet all needs of a package creator. It's only about choosing the right scripts. As an example, there are some packages that put stuff in the Autogenerated package, but I bet that not all of them take care to remove that autogenerated stuff
 again before unloading themselves again.</div>
<div><br>
</div>
<div>Note that SAR files (Smalltalk ARchives) don't have package semantics but contain any installation logic themselves. See <span>SARInstaller>>#fileInFrom:.</span> They can have two install scripts for a preamble and a postscript but no uninstall scripts.
 However, they could load any package which contains a preambleOfRemoval or postscriptOfRemoval.</div>
<div><span style="font-size: 12pt;"><br>
</span></div>
<div><span style="font-size: 12pt;">Another way next to Monticello scripts and SAR install scripts is to
</span><span style="font-size: 12pt;">organize</span><span style="font-size: 12pt;">
</span><span style="font-size: 12pt;">any loading/unloading logic in the class-side </span><span style="font-size: 12pt;">#initialize and #unload methods
</span><span style="font-size: 12pt;">of any class. #initialize is sent after a package with a new definition of this method is loaded, and #unload is sent before the class is removed. See <span>MCMethodDefinition>>#postload and <span>Class>>#removeFromSystem:.</span></span></span></div>
<div><br>
</div>
<div>HTH,</div>
<div>Christoph</div>
<div><br>
</div>
</span></span></span></span></span></span></span></span></span></div>
<p></p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von rabbit <rabbit@callistohouse.org><br>
<b>Gesendet:</b> Freitag, 21. Oktober 2022 14:32:53<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Packaging conventions for Objectland - The Worlds of Squeak (was: Objectland - The Worlds of Squeak)</font>
<div> </div>
</div>
<div><br>
<div dir="ltr">Hi Christoph, an interesting area and I have a couple of questions and an solution suggestion.</div>
<div dir="ltr"><br>
<blockquote type="cite">On Oct 20, 2022, at 15:27, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<meta name="Generator" content="Microsoft Exchange Server">
 <style>
<!--
.EmailQuote
        {margin-left:1pt;
        padding-left:4pt;
        border-left-width:2px;
        border-left-style:solid;
        border-left-color:rgb(128,0,0)}
-->
</style>
<meta content="text/html; charset=UTF-8">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<p>Hi Dave,</p>
<p><br>
</p>
<p>> <span style="font-size:12pt">  "Reloadable means that I can completely remove a package from the</span></p>
<div>>   image, then add it back in, and everything still works."</div>
<div>> </div>
<div>> But I would also add that I expect that the process of unloading</div>
<div>> a package does not leave me with dirty Monticello packages.</div>
<div><br>
</div>
<div>+1. In terms of Monticello semantics, this will (or should) usually not happen. To my knowledge, there is only a small set of exceptions to this rule:</div>
<div><br>
</div>
<div>E1. You have defined extension methods in your package that should be override methods instead (i.e., you forgot the -override suffix at the end of the method category name). Once such a package is unloaded, the original methods will not be restored. Unfortunately,
 this seems to be a pretty unknown fact. I know of a lot of students (including my past self) that do not know this and thus accidentally make their package effectively un-unloadable because they have extended-not-overridden any important method in a system
 package.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
What does an -override category name extension do for us? If the method name is overridden, unload removes the method even if it did switch categories I believe. Or is it possible to unload a specific category and leave the other category present. Yet I still
 don’t see how that protects an overridden method.
<div><br>
</div>
<div>My idea here is to only unload the method version in the unloading package and make sure we leave/revert the previous version that came from no previous version of the package being unloaded that may have loaded over a previous self.</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<div>E2. You have defined overlapping packages (see below).</div>
<div>E3. The unloading process fails or is manually interrupted.</div>
<div>E4. A postscript/preamble of removal uses the Compiler/ClassOrganizer to touch other packages, e.g., to clean up Autogenerated methods.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
Would it help to have a preunload and unpostscript, in the MCZ / SAR?</div>
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<div><br>
</div>
<div>> <span style="font-size:12pt">If I </span><span style="font-size:12pt">have (for example) package MorphicExtras-Examples</span></div>
<div><span style="font-size:12pt"><br>
</span></div>
<div><span style="font-size:12pt">Wait a minute ... Why do you have a *package* named MorphicExtras-Examples? In a current Trunk image, there is a MorphicExtras package only. MorphicExtras-Examples is just a system category in that package. And deliberately defining
 overlapping packages is something that I would consider unidiomatic, Monticello does not expect this. (Or was your argument that is should do?)</span></div>
<div><span style="font-size:12pt"><br>
</span></div>
<div><span style="font-size:12pt">If I unload MorphicExtras, my image hangs indeed because unfortunately, the system (Morphic) still depends on it. In my case, because the class Command is used in BorderedMorph and many others. Improving the decoupling between this
 and many other pairs of packages is still an open to-do that seems to be connected with a lot of design decisions. Maybe we should increase the granularity of our <span>PackageDependencyTest to make any progress on this issue more visible and to avoid further
 regressions in the form of additional coupling with two already dependent packages?</span></span></div>
<div><span style="font-size:12pt"><br>
</span></div>
<div><span style="font-size:12pt">Best,</span></div>
<div><span style="font-size:12pt">Christoph</span></div>
<p></p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis@mail.msen.com><br>
<b>Gesendet:</b> Donnerstag, 20. Oktober 2022 18:33:09<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Packaging conventions for Objectland - The Worlds of Squeak (was: Objectland - The Worlds of Squeak)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div class="PlainText">Objectland may have been a poor example for me to pick. It was
<br>
fresh in my mind because it is a recent addition.<br>
<br>
In my initial mail, I said this:<br>
<br>
  "Reloadable means that I can completely remove a package from the<br>
  image, then add it back in, and everything still works."<br>
<br>
But I would also add that I expect that the process of unloading<br>
a package does not leave me with dirty Monticello packages. If I<br>
have (for example) package MorphicExtras-Examples and I unload that<br>
package, then the MorphicExtras package is going to be inconsistent.<br>
<br>
I would like my hypothetical reloadable package to leave the image<br>
in a consistent state after unloading the package, and I would<br>
like the image to be restored to a consistent state after I reload<br>
the package.<br>
<br>
I understand now that making Objectland into a reloadable package<br>
is probably not a good thing to do, for the reasons given below.<br>
But just to work with that as an example, if my goal was to make<br>
ObjectLand be a reloadable package, then putting in a package<br>
called Objectland-Morphic would make this possible without affecting<br>
the overall MorphicExtras package. But then as Marcel says, that<br>
would clutter up the package namespace.<br>
<br>
Maybe we do not really have the tools to support this well. Or<br>
maybe my expectations are not realistic. Or maybe both ;-)<br>
<br>
Dave<br>
<br>
<br>
<br>
On Thu, Oct 20, 2022 at 09:32:28AM +0200, Marcel Taeumel wrote:<br>
> Hi all --<br>
> <br>
> I like it that we now have a new "handle" for all the Morphic examples that have been living in the image for a very long time, mostly in the "MorphicExtras" package, sometimes "Etoys".<br>
> <br>
> Personally, I think that "MorphicExtras" and "Etoys" are the packages here that need cleaning up with the potential to unload and reload. There will always be some new examples around Morphic that need a place to live. Attaching the "Objectland" label to
 every tiny example thing does not feel right. "MorphicExtras-Examples" might be a more fitting label or category.<br>
> <br>
> "Objectland" is just one possible entry point to a selected set of examples. There can be others. The "Parts Bin" is already there, providing access to almost the same set of things. The dominant decomposition seems to be along "MorphicExtras-Examples" ...
 or "-Demo" ... I think ... "Objectland" and "Partsbin" are cross-cutting.<br>
> <br>
> Best,<br>
> Marcel<br>
> Am 20.10.2022 02:32:04 schrieb David T. Lewis <lewis@mail.msen.com>:<br>
> I am a huge fan of Objectland, and I am also a big proponent of reloadable<br>
> packages. Reloadable means that I can completely remove a package from the<br>
> image, then add it back in, and everything still works.<br>
> <br>
> With the recent addition of Objectand to trunk (yay!) I want to also note<br>
> that this seems like a great candidate for a reloadable package. After all,<br>
> we just loaded it, so we know that part works. All we need to do is make<br>
> sure we can unload it and then put it back in.<br>
> <br>
> So this leads to a question - if we want this to be reloadable, then<br>
> what should be the package name? I am thinking that 'Objectland-Morphic'<br>
> would work well, and would be consistent with existing package names<br>
> such as 'ToolBuilder-Morphic'.<br>
> <br>
> If this makes sense, then can we open a new package 'Objectland-Morphic'<br>
> and start moving these recent changes into that new package? The goal<br>
> would be to be able to remove 'Objectland-Morphic' completely from<br>
> any image, than load it again from the trunk repository with everything<br>
> still 100% working.<br>
> <br>
> Dave<br>
> <br>
<br>
> <br>
<br>
<br>
</div>
</span></font><span></span><br>
</div>
</blockquote>
<br>
<div><span style="color:rgb(0,0,0)">—</span><br style="color:rgb(0,0,0)">
<span style="color:rgb(0,0,0)">Have a good one; keep it, light.</span><br style="color:rgb(0,0,0)">
<span style="color:rgb(0,0,0)">Kindly, langohr . .. … ‘…^,^ 🐇🐇🐇</span><br style="color:rgb(0,0,0)">
<br style="color:rgb(0,0,0)">
<span style="color:rgb(0,0,0)">Sent from Callisto House Mobile - Europa </span><br style="color:rgb(0,0,0)">
<span style="color:rgb(0,0,0)">:: decentralized mobile homeless solutions ::</span></div>
</div>
</div>
</div>
</body>
</html>