[Seaside] Seaside, Traits, portability

stephane ducasse stephane.ducasse at free.fr
Wed May 2 14:44:52 UTC 2007

This fits better the arguments I can understand :)

>> 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
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the Seaside mailing list