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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project