On Feb 9, 2008, at 22:18 , Igor Stasenko wrote:

> On 09/02/2008, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> On Feb 9, 2008, at 6:52 , Igor Stasenko wrote:
>>
>>> 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.
>>
>> Tweak does something similar, its graphical objects are composed of
>> "aspects", for example "fill", "border", "geometry" etc.:
>>
>> http://tweakproject.org/TECHNOLOGY/Documentation/
>>
>> The current implementation uses delegation rather than Traits,
>> though. There is a gazillion of delegation methods in the base
>> object, possibly Traits would allow the structure to be more
>> explicit ...
>>
>
> Yes, it should help with making things more explicit and use direct
> calls rather than delegation.
> As for example, a Fill aspect
> http://tweakproject.org/TECHNOLOGY/Documentation/PlayerAspects/#fill
>
> you really don't need to keep that much state, if your only intent is
> to fill with solid color.

In Tweak this is not state, just protocol (that's what I meant with  
"delegation methods").

> So, we can easily divide different fill styles into different  
> categories:
> SolidFill (color)
> GradientFill (colorRamp, gradientType)
> MySuperiorFill (...)
>
> each kind of fill can require own, unique set of state.

That is exactly how it is implemented, there are different Fill  
classes with different state. They share a common protocol though.  
You could ask a NoneFill for its color and it would answer transparent.

- Bert -