Some emails about traits from their father @ google :)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Very nice post!
Alexandre On 5 Jan 2010, at 15:23, Stéphane Ducasse wrote: > > > > Some emails about traits from their father @ google :) > >> Hi Stef >> >> Sorry for the late reply. I'm just going through my email after the >> Christmas break... >> >> > Could someone please come up with ONE example where MI (traits in >> particular) solve an *actual* problem and not just some academic BS? >> >> I have encountered a bunch of cases in my every-day work at Google >> where single inheritance was not good enough to write the >> functionality that we needed without (a) code duplication and/or >> (b) boilerplate for object delegation (plus the associated >> complexity/slow-down/etc.). This was getting so annoying that I >> went through the hassle of implementing a template-based traits >> mechanism in C++ that we have been using quite regularly. >> >> For example, we have been designing and implementing a very complex >> framework for efficient handling of massive entity/relation graphs >> (billions of nodes). Since we needed this framework to be general >> across multiple aspects, we simply couldn't come up with a good way >> of doing this without some sort of MI, and traits proved to be >> extremely useful. So, based on my experience, I certainly have seen >> plenty of real-world applications where traits can make a >> tremendous difference!! >> >> That said, I can absolutely see that an overuse of traits can also >> add a lot of additional complexity. But in my opinion, this is not >> specific to traits and much more applies to almost any concept when >> it is overused. Consider for example single inheritance. If someone >> needs a class with 50 methods and decide to split this into a 10- >> level deep class hierarchy (just in case that somebody might want >> to reuse a part of it later), this will annoy a lot of other people >> and make things unnecessary complex. Similarly, if somebody splits >> a method with a 20 line algorithm into 10 helper methods with hard- >> to-understand names and consisting of only 2 lines each, this will >> probably make things much harder to understand (although having >> small methods is generally a good thing). >> So, despite the fact that the concepts of single inheritance and >> (helper-)methods can be overused, I'm sure that neither of us would >> argue that they are bad/useless in the first place. And this is the >> same for any of the other nice programming concepts that come to >> mind, like meta-programming and closures (as much as I love >> closures for parametrization, overuse of functional elements can >> make code really hard to understand as well...) >> >> From my point of view, the same applies to traits: If traits are >> used in cases where they actually bring a benefit, i.e., they >> factor together a set of methods that conceptually and logically >> belong together and actually facilitate code reuse, they have been >> very useful to me. >> >> >> Happy New Year and all the best, >> Nathanael >> > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Knowing nathanael it should be quite cool.
Too bad google got him.... This is why I would love to have a traits based collection library :) > Very nice post! > > Alexandre > > > On 5 Jan 2010, at 15:23, Stéphane Ducasse wrote: > >> >> >> >> Some emails about traits from their father @ google :) >> >>> Hi Stef >>> >>> Sorry for the late reply. I'm just going through my email after the >>> Christmas break... >>> >>>> Could someone please come up with ONE example where MI (traits in >>> particular) solve an *actual* problem and not just some academic BS? >>> >>> I have encountered a bunch of cases in my every-day work at Google >>> where single inheritance was not good enough to write the >>> functionality that we needed without (a) code duplication and/or >>> (b) boilerplate for object delegation (plus the associated >>> complexity/slow-down/etc.). This was getting so annoying that I >>> went through the hassle of implementing a template-based traits >>> mechanism in C++ that we have been using quite regularly. >>> >>> For example, we have been designing and implementing a very complex >>> framework for efficient handling of massive entity/relation graphs >>> (billions of nodes). Since we needed this framework to be general >>> across multiple aspects, we simply couldn't come up with a good way >>> of doing this without some sort of MI, and traits proved to be >>> extremely useful. So, based on my experience, I certainly have seen >>> plenty of real-world applications where traits can make a >>> tremendous difference!! >>> >>> That said, I can absolutely see that an overuse of traits can also >>> add a lot of additional complexity. But in my opinion, this is not >>> specific to traits and much more applies to almost any concept when >>> it is overused. Consider for example single inheritance. If someone >>> needs a class with 50 methods and decide to split this into a 10- >>> level deep class hierarchy (just in case that somebody might want >>> to reuse a part of it later), this will annoy a lot of other people >>> and make things unnecessary complex. Similarly, if somebody splits >>> a method with a 20 line algorithm into 10 helper methods with hard- >>> to-understand names and consisting of only 2 lines each, this will >>> probably make things much harder to understand (although having >>> small methods is generally a good thing). >>> So, despite the fact that the concepts of single inheritance and >>> (helper-)methods can be overused, I'm sure that neither of us would >>> argue that they are bad/useless in the first place. And this is the >>> same for any of the other nice programming concepts that come to >>> mind, like meta-programming and closures (as much as I love >>> closures for parametrization, overuse of functional elements can >>> make code really hard to understand as well...) >>> >>> From my point of view, the same applies to traits: If traits are >>> used in cases where they actually bring a benefit, i.e., they >>> factor together a set of methods that conceptually and logically >>> belong together and actually facilitate code reuse, they have been >>> very useful to me. >>> >>> >>> Happy New Year and all the best, >>> Nathanael >>> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |