[Seaside] Seaside, Traits, portability

[stephane ducasse]

Yes!
damien and lukas are adding the minimal traits support to OB.
Nile is really cool. I hope that people will like it.

In fact I do not know why but some simple menu to define traits and  
other siple functionality disappeared
when we released 3.9 :(

> I thought Damian's Squeak-dev images had working Traits support,  
> no?  If so, why don't you go ahead with Pier and Magritte and see  
> how it goes.  If it works well and maintains portability then it's  
> easier for everyone to think about a Seaside traits branch.
>
> Lukas Renggli wrote:
>>> Sorry but I do not understand what you are saying.
>>> I'm just saying that the argument against trait could be that you do
>>> not have adequate browsers
>>> to code with them, not portability since we can remove them.
>>> I would like to hear what philippe and lukas are thinking about  
>>> that.
>>
>> Since you ask me directly I rephrase here what I already discussed  
>> with Avi:
>>
>> - In favor: Personally I would like to use traits for Seaside (as  
>> well
>> as for Magritte and Pier), as it would avoid a big deal of code
>> duplication and would effectively help solving many problems related
>> to bugs not getting fixed in all places. Traits have absolutely no
>> effect on the runtime (the VM has a flattened view) and they don't
>> affect portability with other versions of Squeak and Smalltalk
>> dialects. Current development of Seaside happens solely in Squeak  
>> by a
>> very small group of contributors.
>>
>> - Against: The current state of the Traits implementation makes it
>> impossible for me to use them. I need a working and up-to date  
>> browser
>> that is fully traits aware. Moreover I require that Monticello loads
>> the Traits transparently, this means that if I load a package in  
>> 3.9 I
>> get traits and if I load the same package anywhere else I get a
>> flattened view (I believe this is possible in a backward compatible
>> way). Next I want to be able to flatten them properly, not with  
>> one of
>> those scripts floating around but in a propre way built into the
>> system. As long as these 3 things are missing I think it is
>> unrealistic to use Traits.
>>
>> To come back to the initial proposal that caused this discussion:
>> "Modelling the attribute modules of XHTML using Traits".  
>> Interestingly
>> the XHTML modules are defined very similarly to Traits (multiple
>> inheritance without state). There are two orthogonal goals here: (1)
>> to avoid code duplication and, (2) to model attributes so that they
>> are only defined on tags they support. I think the best idea for now
>> is to implement the attributes too high in the hierarchy like it is
>> for #tabIndex:, #accessKey: and many other attributes already today.
>> This follows (1) but sacrifies (2). If we had a meta-model we could
>> even validate that according to a specified DTD during the  
>> development
>> phase.
>>
>> Cheers,
>> Lukas
>>
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>