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.
>>
>> "!
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>
>
>