stan
as one of the trait "guy" we should consider that
- probably what we got can be improved
for example I was discussing about the implementation in
javascript and tom is proposing to have a
a shallow rename of methods + adding a requirement instead of
an alias (this way you can limit the interface explosion)
- I did not like the stateful traits even if this is my idea.
what we tried to do what do make sure that we do not have to recompile
the code in each user.
Now since methods are not shared (I'm sad about that) between trait
user then we could recompile
the methods for each user and users could have different states and
state layout.
- for state the question in initialize: how do we initialize trait
state in the composite in an elegant way
in ambianttalk we get
T1>>initialize
T2>>initialize
C
T1 initialize -> T1init
T2 initialize -> T2init
and initialize
self T1init.
self T2init
- for Plug like delegatee we are working with people from KUL on
understanding a kind of subobject trait based approach.
We will send information when the paper is published. But you can read
the ecoop paper of marko van dooren
- Did you check the solution proposed in VW to have state in traits?
I do not remember it (shame on my weak memory)
>
> To test out the possibilities of using traits for refactoring, I had a go at
> rationalising OmniBrowser/OmniBrowser2.
Good! I like the idea to have traits shared between browser.
>
> This showed up that it appears to be possible to use the current traits
> implementation in a 'quasi-stateful' manner. that is, you can directly
> address the variables of a trait's 'hosting' class. This is rather contrary
> to my previous understanding of stateless traits. Is this normal behaviour?
>
> I've written up the details here.
>
> http://neat-sheet.com/development-blog.html/
>
> ...Stan
> --
> View this message in context:
> http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571120.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
