[Pharo-project] About SimpleMorphic

Igor Stasenko siguctua at gmail.com
Sun Nov 7 20:50:17 CET 2010


On 7 November 2010 21:17, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2010/11/7 Igor Stasenko <siguctua at gmail.com>:
>>> Talking about complexity, let's take for example, morph layout. This is
>>> started with #doLayoutIn: in Pharo and #doLayoutIfNeeded in SimpleMorphic.
>>>
>>> In Pharo, this method calls #adjustLayoutBounds: (19), #layout:in: (149),
>>> #layoutProportionallyIn: (10), #computeCellArrangement:in:horizontal:target:
>>> (87), #computeGlobalCellArrangement:in:horizontal:wrap:spacing: (31),
>>> #computeCellSizes:in:horizontal: (30),
>>> #computeExtraSpacing:in:horizontal:target: (136), #layoutLeftToRight:in:
>>> (91), #layoutTopToBottom:in: (91), #placeCells:in:horizontal:target: (70).
>>> The numbers in parenthesis are the sum of the lines of code of the
>>> implementors. Total lines of code for layout (taking only these most
>>> important methods) is 714. I doubt there are many people who really
>>> understand all of this code.
>>>
>>> In SimpleMorphic (Cuis), this calls #layoutSubmorphsIn: (10),
>>> #applyLayoutFrameIn: (11), #layout:in: (24). Total lines of code is 45. I
>>> believe any smalltalker could understand these in just minutes.
>>>
>>
>> Indeed, a morphic layout logic always felt overly complicated to me.
>> It hard, because you don't know,
>> if you can remove/replace anything from there and still have a working
>> code. Good to see that you have managed to deal with that.
>>
>
> The question that immediately arises from such complexity is :
> - what are the features we want to implement ?
>
> If we are not able to provide an answer, that means we can't even
> write tests, and that also means we can't modify/refactor the code.
> In such case, we tend to write more code outside existing one and so
> doing are just making things worse (more code more complexity).
>
> I suspect (but I did not check) that Juan's work in Cuis is the best
> thing to do in such case.
> While at it, we should also write tests now that we have testable features.
>

it is hard to say, what layout policies we may need, and what can be
removed/simplified. What i feel wrong with scheme,
that from message names it feels like a container morph is responsible
for layout,
while i think, that it is submorph(s) themselves should be responsible
and know how to place
them within parent morph.

> Nicolas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-project mailing list