[Seaside] Seaside, Traits, portability

[Lukas Renggli]

> 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