I like this decomposition of a large interface into separate objects. Stef
column := AlignmentMorph newColumn.
column color: Color white. column layout shrinkWrap. "v and h both"
column border width: 0; color: Color black.
column childLayout inset: 1; wrapCentering: #center; cellPositioning: #center.
Cons: - a code is a bit more elaborate. That because, of course, we cannot merge everything into single cascade.
Pros: - from code it is clear, which properties belong to which parts of functionality. You cannot confuse, for instance, whether 'wrapCentering' property controls morph's own layout or a layout of its children - most important, we can considerably shrink Morph's protocol by removing all direct accessors and instead put them into delegated behaviors.
More than that, a delegates don't need to be a dummy state holders (like most of properties are now), but actually an object(s) which conform to certain protocol..
For instance, if we have a 'border' as a delegate, and morph wants to draw it, it could just tell:
MyMorph>>drawOn: aCanvas self border drawOn: aCanvas
btw, then it is actually makes sense having a BorderedMorph subclass, which a) introduces 'border' delegate b) cares to draw its border in contrast to Morph who shouldn't.
As well as in case of layouts, you can tell:
morph layout changed.
or
morph childLayout layOutChildren.
etc.
-- Best regards, Igor Stasenko.