> On 02.04.2016, at 20:39, Chris Muller <asqueaker at gmail.com> wrote:
> 
>> Why not adhere to the copy-on-write scheme for forms in Morphic? That’s how it was designed.
>> 
>> E.g. when you make a green-handle copy of a SystemWindow, why would you want to deep-copy all the icons?
> 
> I don't.  I want to deepCopy the form bits when I invoke the
> green-halo it on a SketchMorph, not a SystemWindow.  That's what
> Morph-cmm.1096 does, without affecting it when copying SystemWindows
> or anything else besides a SketchMorph.
> 
> But you said the problem with that is that Etoys students are putting
> their behaviors directly on SketchMorphs instead of something more
> abstract like a PlayerMorph.  With a PlayerMorph they could set his
> #fillStyle to some Form which would still share on veryDeepCopy, and
> yet with my #veryDeepFixup: in SketchMorph, the green-halo would ALSO
> work properly when invoked directly on a SketchMorph -- the best of
> both worlds.

That’s not at all how Etoys works. Yes it’s a prototype-based fat-object OO system on top of Smalltalk, but that’s not how students think about it. Students do not deal with morphs or fill styles at all. 

As in many prototype-based systems, copying is a fundamental operation, and it needs to be efficient. Duplicating the bits of a form is not efficient, especially not when they get stored in projects.

> But we have to break this common use-case so that this design choice
> to use SketchMorphs everywhere, will be more memory-efficient..
> Sigh..

I’d say that modifying the bits of a SketchMorph using low-level methods while expecting a copy to not be affected is very far from a common use case. It’s not at all unreasonable, but it is not what it’s designed for, or commonly used for.

>>> Instead, before you modify a form (which is an extremely rare operation compared to all uses of forms), make a copy of it.
> 
> As I said, that's exactly what I did -- or thought I was doing.  I
> just did it via the green halo because I expected it to behave as it
> does on all other Morphs -- to make a meaningfully separate copy.

I can see what you’re getting at, but we can’t put the burden on the students. But let’s think about what it would take to have our cake and eat it, too.

What if we could automate the copy-on-write behavior? If the form used in a SketchMorph could be “locked down” so that any attempt at modifying it could be caught. Then it could either just warn the user, or it could be duplicated automatically.

I can’t easily think of a solution, but maybe it’s possible.

- Bert -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4207 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160403/18c3350e/smime.bin