On Sat, 24 Feb 2007 07:13:15 +0100, Andreas Raab wrote:
> Klaus D. Witzel wrote:
>> As can be seen from the attached source code, W3's "modules" when  
>> implemented as Traits can be attached easily to Todd's fine classes,  
>> without any side effect, in a Monticello-friendly fashion. And if  
>> someone would decide to get rid of such "crap" then the Traits can as  
>> well be deimplemented without any side effect.
>
> That is a very interesting (and to me novel) approach of applying  
> traits. I have two questions about this:
> a) Since there is no code in the traits yet, it is hard to say how the  
> use of state would affect the ability to mix the various traits  
> depending on the ui framework chosen. Do you have any idea how to go  
> about state?

I think that state must be hold in a subinstance of Model (with/without  
persistency). There can be many different models, but every traits layer  
(=library) naturally defines its own (=state). The model may reference the  
base material (html+css DOM in our case) or initially translate it for  
easing/speeding up accessors.

It will depend on the subproblem how/from where the model is referenced.  
For example an instance of MorphicLayoutManagerModel can be referenced  
with a dynamic variable, for the time it does its job (it resides only in  
the stack). Thereafter the components can have their layout accessible  
 from their respective view and LayoutManager can go away.

Does the above indicate how to mix various traits depending on the ui  
framework chosen?

> b) Is there any fundamental difference in doing what you did (using  
> traits) compared to what you would achieve with inheritance?

Yes. The html+css DOM base package must not neccessarily cooperate and the  
(library) boundaries are sharper (i.e. not just at the level of  
system/message category names).

> Since practically all subclasses are immediate children of the DOM node,  
> one could imagine to introduce a bit more hierarchy instead of mixing in  
> traits. How do you feel about that?

My perspective here is that of a team manager who wants his team to be  
very productive. Therefore I would not allow overrides between a base  
library and, say, a layout library. Instead, just a clear contract in form  
of methods required and methods provided (and *no* global references ;-)

As an example, if we take the part of your last question from above as  
"multiple ui frameworks, one of them to be choosen at run time" then the  
degree of isolation between the layers can raise but also can bring Rome  
to fall [pun intended].

The rest (for example, exploiting software composition) must be open to  
the creativity of the team members.

>> I would appreciate if the Traits discussion could be directed towards  
>> practical solutions for this practical problem. I hope that the  
>> html+css project can benefit from your expertise, experience and  
>> opinion.
>
> It's definitely nice to see something novel like this. Are you planning  
> on continued development?

Yes. But as already mentioned, I either become a layout expert for Morphic  
and Tweak, or else somebody can help me with that (as a tutor, mentor?).  
I'd be happily do all the necessary coding (when time permits).

> I would be very curious to follow this project to see how it goes as  
> more code needs to be handled.

Thank you for your attention Andreas.

/Klaus

> Cheers,
>    - Andreas
>
>