Fwd: traits :)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: traits :)

Stéphane Ducasse



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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: traits :)

Alexandre Bergel
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: traits :)

Stéphane Ducasse
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