[squeak-dev] Packaging conventions for Objectland - The Worlds of Squeak (was: Objectland - The Worlds of Squeak)
Christoph.Thiede at student.hpi.uni-potsdam.de
Thu Oct 20 19:27:29 UTC 2022
> "Reloadable means that I can completely remove a package from the
> image, then add it back in, and everything still works."
> But I would also add that I expect that the process of unloading
> a package does not leave me with dirty Monticello packages.
+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:
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.
E2. You have defined overlapping packages (see below).
E3. The unloading process fails or is manually interrupted.
E4. A postscript/preamble of removal uses the Compiler/ClassOrganizer to touch other packages, e.g., to clean up Autogenerated methods.
> If I have (for example) package MorphicExtras-Examples
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?)
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 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?
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis at mail.msen.com>
Gesendet: Donnerstag, 20. Oktober 2022 18:33:09
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Packaging conventions for Objectland - The Worlds of Squeak (was: Objectland - The Worlds of Squeak)
Objectland may have been a poor example for me to pick. It was
fresh in my mind because it is a recent addition.
In my initial mail, I said this:
"Reloadable means that I can completely remove a package from the
image, then add it back in, and everything still works."
But I would also add that I expect that the process of unloading
a package does not leave me with dirty Monticello packages. If I
have (for example) package MorphicExtras-Examples and I unload that
package, then the MorphicExtras package is going to be inconsistent.
I would like my hypothetical reloadable package to leave the image
in a consistent state after unloading the package, and I would
like the image to be restored to a consistent state after I reload
I understand now that making Objectland into a reloadable package
is probably not a good thing to do, for the reasons given below.
But just to work with that as an example, if my goal was to make
ObjectLand be a reloadable package, then putting in a package
called Objectland-Morphic would make this possible without affecting
the overall MorphicExtras package. But then as Marcel says, that
would clutter up the package namespace.
Maybe we do not really have the tools to support this well. Or
maybe my expectations are not realistic. Or maybe both ;-)
On Thu, Oct 20, 2022 at 09:32:28AM +0200, Marcel Taeumel wrote:
> Hi all --
> 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".
> 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.
> "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.
> Am 20.10.2022 02:32:04 schrieb David T. Lewis <lewis at mail.msen.com>:
> I am a huge fan of Objectland, and I am also a big proponent of reloadable
> packages. Reloadable means that I can completely remove a package from the
> image, then add it back in, and everything still works.
> With the recent addition of Objectand to trunk (yay!) I want to also note
> that this seems like a great candidate for a reloadable package. After all,
> we just loaded it, so we know that part works. All we need to do is make
> sure we can unload it and then put it back in.
> So this leads to a question - if we want this to be reloadable, then
> what should be the package name? I am thinking that 'Objectland-Morphic'
> would work well, and would be consistent with existing package names
> such as 'ToolBuilder-Morphic'.
> If this makes sense, then can we open a new package 'Objectland-Morphic'
> and start moving these recent changes into that new package? The goal
> would be to be able to remove 'Objectland-Morphic' completely from
> any image, than load it again from the trunk repository with everything
> still 100% working.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev