On 2022-10-20T11:32:28+02:00, marcel.taeumel@hpi.de 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.
+1. I'd like to add that we have added the most examples to the MorphicExtras package instead of Morphic because some of them include larger resources. The other force is to keep documentation close to the sources, which also speaks against moving all examples to a more distant package.
Best, Christoph
Best, Marcel 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.
Dave