[Seaside] Seaside, Traits, portability
jbjohns at libsource.com
Sat May 5 17:01:53 UTC 2007
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
More information about the Seaside