[Cuis-dev] [RFC][Proposal] Refactoring of World Morph

[Hilaire Fernandes]

Hi Juan,

What will be left to a PasteUpMorph? What a PasteUpMorph can do a Morph 
can't. For DrGeo I still use a PasteUpMorph for the drawable, but I am 
not sure it is mandatory, and it is for historical reason because of 
tile programming then

If I am right, in Squeak's PasteUpMorph the purpose is let user drop 
morphs of any kind for visual programming with tiles.

In The Cuis base image, all instances of PasteUpMorph are World.

By the way I met this funny behavior:

    *PasteUpMorph newWorld;newWorld;newWorld. (repeat at will)*
    **PasteUpMorph allInstances * *=> #( [world]  [world]  [world] 
    [world]  [world]) * PasteUpMorph allInstances => #( [world]  [world]) *

Duplicated World seems to vanish.

Then:

*PasteUpMorph newWorld openInWorld*

makes the environment unhappy.

As long as there is only one World correctly handled in Cuis, it makes 
sense to safeguard the environment with a singleton or alike behavior.

AFAIK, there is no such things as Squeak's Project in Cuis.

Take care

Hilaire

Le 23/10/2020 à 20:13, Juan Vuletich via Cuis-dev a écrit :
> Today, the morphic world is an instance of PasteUpMorph. But 
> PasteUpMorph is a more general class, just an area where you can play 
> with submorphs. For World functionality, there is an instance var 
> called 'worldState' that holds an instance of WorldState. This means 
> that PasteUpMorph has two very different purposes, and that the World 
> is actually split in two classes.
>
> I want to make the world an instance of a new class, WorldMorph, that 
> is subclass of PasteUpMorph. This allows pushing down a lot of 
> world-specific stuff from PasteUpMorph, making the world a self 
> sufficient, meaningful object, and remove the ugly WorldState class. 
> All this also means a reduction in the loc count for these objects by 
> 10%.
>
> Still, before pushing these changes, I'd like to know if there's a 
> downside, or any feedback.

-- 
GNU Dr. Geo
http://drgeo.eu
https://pouet.chapril.org/@hilaire

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201024/e2deb09b/attachment.htm>