Lukas Renggli wrote: > >>> 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. > > What is the benefit for the maintainers of the two browser? > I should imagine none ;)
I wouldn't advocate this approach for two projects that are going to remain separate. While there would be a small saving in double handling bugs in the common methods, as in http://code.google.com/p/pharo/issues/detail?id=1887&can=1&q=copy&sort=-id&colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty Issue 1887 it wouldn't outweigh the hassle. > To me this doesn't make any sense: the Traits themselves don't have > any meaning, they are just there to share code that randomly matches > in both implementations. I imagine that changing a trait for one > browser almost certainly breaks something in the other browser? Who > ensures that the trait use is kept in sync between the two > implementations? How can I avoid to accidentally leak code from one > browser into the other one? What happens if one of the browsers > reactors its class hierarchy? > > To me this all looks like a lot more work, more things to maintain and > think about. > Again, I wouldn't advocate this for two actively, separately maintained, packages. But in the hypothetical where you did try this: > changing a trait for one browser almost certainly breaks something in the > other browser I think if you wanted the methods no longer to be the same, you would implement the change back in your version of the class. The other user would see no change. > Who ensures that the trait use is kept in sync between the two > implementations? How can I avoid to accidentally leak code from one > browser into the other one? The person who made any mod would have the choice of doing so unilaterally, in the local class, or of negotiating a common change. You do get prompted to ask whether you want to change the trait or make the change locally, but you could accidentally change the trait by clicking the wrong option. > What happens if one of the browsers reactors its class hierarchy? > Then clearly all bets would be off, because they are no longer common in that sense. The refactoring version would repatriate its traits into methods and go from there. I could see the trait approach being useful in the following circumstances: The two versions decide to get together and heal the fork. Taking the functionality apart into traits helps to identify what is different, what actually needs to be different, and how it can be moved to non-interfering places. or Before the fork takes place, the two versions decide that forking is necessary, but they wish to retain as much commonality as possible. Cheers, ...Stan -- View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571540.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
