I often use copy in default access methods. The motivation is increaed 
robustness; it can be very risky to modify a collection. The 'submorphs 
copy' is presumably a way of implementing a read-only reference, ensuring 
that clients don't modify the collection in unsafe ways. One example is 
violating the submorph/owner invariant. Another is that the result of this 
expression is undefined:
        submorphs do: [:m | ........ ifTue: [m delete]])

Cheers
-Trygve

At 21:07 25.07.2005, you wrote:

>Sounds like a good idea to me, too... if it works, we could make using a
>copy the exception rather than the rule.  E.g. change
>PasteUpMorph>>imposeListViewSortingBy: to do "self submorphs copy",
>which it seems like it probably should be doing.  I can't imagine there
>are too many cases where a copy is really required.
>
>I may try making this change in the image I regularly use also, to see
>if anything starts breaking.
>
>- Doug
>
>
>On Sun, 24 Jul 2005 20:05:01 -0400, "Eddie Cottongim"
><cottonsqueak at earthlink.net> said:
> > I think you are correct. I was afraid to try that, but if it's safe, I'd
> > like it a lot better than playing whack-a-mole with "submorphs size".
> >
> > The only thing I can find to the contrary is this note from
> > PasteUpMorph>>imposeListViewSortingBy: retrieving:
> >
> >     self submorphs "important that it be a copy" do:
> >         [:aMorph |
> >             rep _ aMorph listViewLineForFieldList: fieldListSelectors.
> >             rep hResizing: #spaceFill.
> >             self replaceSubmorph: aMorph by: rep].
> >
> > But I think this will actually work either way. I can't seem to break
> > anything by deleting while iterating, which I thought might be a problem.
> >
> > I'm trying it in my image now. Nothing has broken so far... But its not
> > easy to know all the paths are working right.
> >
> > Thanks,
> > Eddie
> >
> > Andreas Raab wrote:
> >
> > > Hi -
> > >
> > > Just out of curiosity: Have you considered simply not copying the
> > > submorphs? I have always wondered what would happen then - likely
> > > nothing since the submorphs are an array (e.g., essentially read-only)
> > > and I cannot remember any client using it in an otherwise problematic
> > > way.
> > >
> > > Cheers,
> > >   - Andreas
> > >
> > > cottonsqueak at earthlink.net wrote:
> > >
> > >> from preamble:
> > >>
> > >> "Change Set:        submorphsCleanup-efc
> > >> Date:            24 July 2005
> > >> Author:            Eddie Cottongim
> > >>
> > >> In profiling for speed, I've noticed that a common culprit for poor
> > >> scaling to large numbers of morphs is unnecessary use of #submorphs
> > >> where the whole collection is not actually needed. There is often a
> > >> trivial replacement that can spare doing the copy, and is probably
> > >> better style. #copy is very fast, but it can introduce O(n*n)
> > >> performance that is noticable when you have a lot of morphs, the machine
> > >> is slow, or both. Also the callers tend to send #submorphs two or three
> > >> times in one method!!
> > >>
> > >> I've gone through what looked like the core morphic classes and carried
> > >> out transformations that looked trivial. I haven't touched more
> > >> complicated cases. The ones I can't get without adding methods or
> > >> rewriting the caller are the complicated Collection selectors that don't
> > >> have a ready equivilent in Morph, and direct submorph access by index,
> > >> which Morph doesn't have for some reason.
> > >>
> > >> The following conversions have been made:
> > >>
> > >> submorphs size -> submorphCount
> > >> submorphs do: -> submorphsDo:
> > >> submorphs last -> lastSubmorph
> > >> submorphs first -> firstSubmorph
> > >> submorphs empty -> (not)hasSubmorphs
> > >> submorphs indexOf: -> submorphsIndexOf:
> > >>
> > >> Those on very slow machines may see some benefit from this in normal
> > >> use. Others may only benefit in extreme cases with a LOT of Morphs.
> > >>
> > >> "!
> > >>
> > >>
> > >> ------------------------------------------------------------------------
> > >>
> > >>
> > >
> > >
> > >
> >
> >


-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway