[Pharo-project] Smells looking at collections
Eliot wrote: Hi Levente, in my experience playing with the Dan and Alan Borning's multiple inheritance implementation getting things to work was one thing, reasonably straighforward, but getting tool support right (file-out format so that things filed back in correctly, etc) was another, an dth ebulk of the work. Looking at your proposal below I see no problem getting it to work but see lots of problems integrating it, e.g. with Monticello, etc. Traits is already integrated with Monticello, supported with tests, etc. As such it is a much less risky or effortful proposition than a new scheme. So with that in mind are there important functional benefits of your scheme's direct state access as compared with traits that use accessors to access state that each user of a trait must implement? i.e. what are the key benefits you see in direct inst var access? best Eliot Hi Eliot, I think there is a strong argument for stateful traits, especially since we are talking about collection smells. One of the main selling points for traits (for me, at least) is that they would allow us to clean up the mess created by inheritance for reuse (Dictionary is a Set) in existing libraries. And obviously to create cleaner libraries going forward. Well, inheritance for reuse is used not just for behavior, but for state as well. Stateful traits would allow for a cleaner separation between inheritance and subtyping. Stateful traits would even allow you to push the separation further and, as part of your design, you could have state-only traits complementing behavior-only traits. Let us not forget that clean concepts are also easier to learn. I think it is much more important to get the concepts right than any existing integration with Monticello. Why does it matter that we have tests and integration if people are not using traits? Cheers, Florin
Hi Florin, 2010/10/26 Florin Mateoc <fmateoc@gmail.com>
Eliot wrote:
Hi Levente,
in my experience playing with the Dan and Alan Borning's multiple inheritance implementation getting things to work was one thing, reasonably straighforward, but getting tool support right (file-out format so that things filed back in correctly, etc) was another, an dth ebulk of the work. Looking at your proposal below I see no problem getting it to work but see lots of problems integrating it, e.g. with Monticello, etc. Traits is already integrated with Monticello, supported with tests, etc. As such it is a much less risky or effortful proposition than a new scheme. So with that in mind are there important functional benefits of your scheme's direct state access as compared with traits that use accessors to access state that each user of a trait must implement? i.e. what are the key benefits you see in direct inst var access?
best Eliot
Hi Eliot,
I think there is a strong argument for stateful traits, especially since we are talking about collection smells. One of the main selling points for traits (for me, at least) is that they would allow us to clean up the mess created by inheritance for reuse (Dictionary is a Set) in existing libraries. And obviously to create cleaner libraries going forward. Well, inheritance for reuse is used not just for behavior, but for state as well. Stateful traits would allow for a cleaner separation between inheritance and subtyping. Stateful traits would even allow you to push the separation further and, as part of your design, you could have state-only traits complementing behavior-only traits. Let us not forget that clean concepts are also easier to learn. I think it is much more important to get the concepts right than any existing integration with Monticello. Why does it matter that we have tests and integration if people are not using traits?
The argument is not over the utility of stateful traits. The argument is over how to access that state. The existing Traits implementation allows indirect access to state, where the Trait uses accessors that must be implemented by a class using the trait. This has the disadvantages listed by Levente, possibility of accessor selectors clashing with existing protocol, lack of privacy and poorer performance. One possible solution is to do a new traits implementation that supports state, but as discussed integration is hard and that could be a lot of work. There are other solutions to explore that could localise the changes. For example imagine adding some special illegal syntax that a variant of the compiler (a compiler mode or a subclass or...) can deal with and using that to reference trait state. Then changes are localised to - the compiler (to compile the syntax down onto the relevant inst vars) - class definition/trait composition (to ensure the state inst vars exist in the class) - shout (to highlight the new syntax) - the decompiler (so decompiled trait code displays the new syntax for trait state access) Another possibility might be a selector privacy hack. The selectors used to access state in a trait are known not to clash in the trait (they ca be so chosen by the trait author not to conflict with anything in the trait) but they cannot be guaranteed not to clash with a user of the trait. So post-compile the selectors for the trait's state could be changed to private values (keys that existed only in the method dictionary of the trait user). This doesn't have the performance of direct inst var access, but it solves the clash and privacy issues. And I expect there are other solutions too. In summary don't argue for or against stateful traits, instead think about how to add state to traits whilst having the most minimal impact on the rest of the infrastructure. best Eliot
Cheers, Florin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 10/26/2010 2:27 PM, Eliot Miranda wrote:
The argument is not over the utility of stateful traits. The argument is over how to access that state. The existing Traits implementation allows indirect access to state, where the Trait uses accessors that must be implemented by a class using the trait. This has the disadvantages listed by Levente, possibility of accessor selectors clashing with existing protocol, lack of privacy and poorer performance. One possible solution is to do a new traits implementation that supports state, but as discussed integration is hard and that could be a lot of work. There are other solutions to explore that could localise the changes.
For example imagine adding some special illegal syntax that a variant of the compiler (a compiler mode or a subclass or...) can deal with and using that to reference trait state. Then changes are localised to - the compiler (to compile the syntax down onto the relevant inst vars) - class definition/trait composition (to ensure the state inst vars exist in the class) - shout (to highlight the new syntax) - the decompiler (so decompiled trait code displays the new syntax for trait state access)
Another possibility might be a selector privacy hack. The selectors used to access state in a trait are known not to clash in the trait (they ca be so chosen by the trait author not to conflict with anything in the trait) but they cannot be guaranteed not to clash with a user of the trait. So post-compile the selectors for the trait's state could be changed to private values (keys that existed only in the method dictionary of the trait user). This doesn't have the performance of direct inst var access, but it solves the clash and privacy issues.
And I expect there are other solutions too.
In summary don't argue for or against stateful traits, instead think about how to add state to traits whilst having the most minimal impact on the rest of the infrastructure.
best Eliot
For me, the utility argument is an important one. I don't care about just making it work, whether I believe in it or not. It's bad enough that I have to do that at my workplace. Then again, they are paying me for it. Cheers, Florin
Hi Florin, On Tue, Oct 26, 2010 at 3:26 PM, Florin Mateoc <fmateoc@gmail.com> wrote:
On 10/26/2010 2:27 PM, Eliot Miranda wrote:
The argument is not over the utility of stateful traits. The argument
is over how to access that state. The
existing Traits implementation allows indirect access to state, where the Trait uses accessors that must be implemented by a class using the trait. This has the disadvantages listed by Levente, possibility of accessor selectors clashing with existing protocol, lack of privacy and poorer performance. One possible solution is to do a new traits implementation that supports state, but as discussed integration is hard and that could be a lot of work. There are other solutions to explore that could localise the changes.
For example imagine adding some special illegal syntax that a variant of the compiler (a compiler mode or a subclass or...) can deal with and using that to reference trait state. Then changes are localised to - the compiler (to compile the syntax down onto the relevant inst vars) - class definition/trait composition (to ensure the state inst vars exist in the class) - shout (to highlight the new syntax) - the decompiler (so decompiled trait code displays the new syntax for trait state access)
Another possibility might be a selector privacy hack. The selectors used to access state in a trait are known not to clash in the trait (they ca be so chosen by the trait author not to conflict with anything in the trait) but they cannot be guaranteed not to clash with a user of the trait. So post-compile the selectors for the trait's state could be changed to private values (keys that existed only in the method dictionary of the trait user). This doesn't have the performance of direct inst var access, but it solves the clash and privacy issues.
And I expect there are other solutions too.
In summary don't argue for or against stateful traits, instead think about how to add state to traits whilst having the most minimal impact on the rest of the infrastructure.
best Eliot
For me, the utility argument is an important one. I don't care about just making it work, whether I believe in it or not. It's bad enough that I have to do that at my workplace. Then again, they are paying me for it.
Whatever. I think you're taking me wrong. I agree that stateful traits are more useful than non. I'm trying to discuss the engineering of them. Are you interestined in realising something you want or are you more interested in scoring points? Or is getting things to work not what you get paid for? Eliot
Cheers, Florin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Eliot Miranda -
Florin Mateoc