Morphs as composition of traits?

stephane ducasse stephane.ducasse at free.fr
Sat Feb 9 08:40:14 UTC 2008


> Here, is my thoughts:
> it's really hard to tell what properties morphs can be kept as  
> basic(core) ones.
> Dimenstions(shape)? No. There is morphs which never show-up on screen
> and therefore don't need any dimension/shape info.
> Visual aspects? Again - no. Depending on morph, they can be very
> different, including colors, borders or font style for text.
>
> So, maybe, i thought, better to think of morph as composition of
> different traits, which in sum defining an original morph.

Yes
Our first example was taken from rectangleMorph and rectangle and all  
the current delegation

> Let me pick an example, to better illustrate what i have in mind
>
> Rectangle morph.
> It should include a 'shape' trait, because rectangle is just a kind of
> shape (lets assume it's a ShapeTrait subclass - RectangularShape).
> Now, with having shape we can speak of different visual aspects, like
> border and fill.

One idea was that rectangleMorph just plug rectangleShapeTrait to gain  
all the rectangle oriented behavior.
>
>
> Okay , we just defined a set of traits which should define a  
> rectange morph.
> Now, is how to build a real instance of it (or class which producing  
> them).
> Instance of such class would require from us a state, which will
> reflect a different trait-based properties of it.
> How about using anonymous classes, and using special methods, in
> traits class, which should describe what state should be included into
> resulting class?

This is interesing. Now the problem is that you may have to recompile  
(and copy down) the methods
where you have instance variable offset conflicts.

>
> Then, we can create a morph class on the fly, using UI by picking
> traits and compositing them, and in result we will have a class, ready
> to work with.
>
> As one of the variants it can be a #statevars method:
>
> FillTrait class>>statevars
> ^ #(fillstyle)
>
> Now suppose we have a class named MorphClassBuilder which simply
> builds for us an anonymous morph class.

Why anonymous? We could just have a normal class
because most of the time you will want to add new behavior to that  
class or resolve conflicts.
>
>
> MorphClassBuilder>>numvars
> | numvars size |
> size := 0.
> self allIncludedTraits do: [:trait | size := size + trait statevars  
> size ].
> ^ size
>
> By having a #numvars, it's easy to add a #new method for our future  
> morph class:
>
> resultingClass addClassMethod: 'new ^ self basicNew' , builder  
> numvars asString.
>
> .. and, it's really easy to add accessors to such class:
>
> MorphClassBuilder>>addAccessors
> | allvars |
> allvars := OrderedCollection new.
> allvars := self allIncludedTraits do:[:trait | allvars addAll: trait
> statevars ].
>
> allvars withIndexDo: [:i :selector |
>   resultingClass compileMethod: selector , ' ^ self at:' , i asString
> . "read accessor"
>   resultingClass compileMethod: selector , ': value  ^ self at:' , i
> asString , ' put: value' . "write accessor"
>
> .. as you can see, nothing really hard, here: just implement a
> MorphClassBuilder, and you'll have a powers to create virtually any
> kind of morph by combining wide variety of traits.
>
> Back to example, our rectangle morph with fill and border require 3  
> state vars:
> - bounds
> - fillstyle
> - borderstyle
>
> So, a MorphClassBuilder should produce a morph class with following  
> methods:
>
> new
>  ^ self basicNew: 3
>
> bounds
>  ^ self at: 1
> bounds: value
>  ^ self at: 1 put: value
>
> fillstyle
>  ^ self at: 2
> fillstyle: value
>  ^ self at: 2 put: value
>
> borderstyle
>  ^ self at: 3
> borderstyle: value
>  ^ self at: 3 put: value
>
>
> I don't know (it's not clear the future of Traits in squeak), but i
> think it's easy to overcome a stateless limits of traits by
> introducing schemes which i just illustrated.
> Also, if you considered given example, being stateless not really an
> issue - it can always can be added dynamically :)
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
>




More information about the Squeak-dev mailing list