On Oct 6, 2008, at 5:45 PM, Bill Schwab wrote:
Alexandre,
Any performance hit aside, I am willing to go along. However, the direction of the crowd generally makes me suspicious vs. reassuring me that something is correct. Granted, this isn't the Visual this-that-or-the-other-thing.CloudyNET marketing group telling us what they think we should do.
Re performance, IIRC, Damien found Nile does well vs. Squeak's streams. It would be interesting to know how much of that is good design vs. traits.
what damien proved is that having accessor does not slow down and that more important that you can optimize too and reuse with traits.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
alexandre@bergel.eu 10/06/08 11:19 AM >>> I agree with your Bill. No strong empirical study have been made that demonstrate the benefit of traits over traditional class inheritance. However, this is hard to achieve, and we do not have resource to conduct such experiment. We are therefore left to our intuition that using traits is better than not using them. But a large crowd (and not only in the research community) has the same intuition.
Cheers, Alexandre
On 6 Oct 2008, at 16:07, Bill Schwab wrote:
Stef, Alexandre,
I will grant you a head start: if you have to copy code, it's not the same thing. My next question would be whether a competitive "say it once" design could be realized with composition and single inheritance. Alexandre refers to use cases the show an advantage, and I do not dispute that. I am mostly just curious at this point. Is there more or less overhead specifying the traits vs. arranging for good composition? My guess would be that the traits win, but I have no data to support that. Is there a performance advantage either way?
Unless traits are (whether used or not) very expensive at runtime, I would argue that anything that gets us better test coverage is a good thing.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
stephane.ducasse@inria.fr 10/06/08 2:32 AM >>> you can achieve the same with copy and paste or code generation. What is nice with traits is that they represent a bloc of coherent behavior that can be parametrized. Load the latest Collection-Tests from the pharo source. This is just the start but this is quite cool. Check TEmptyTest. It is applied to OrderedCollection, Basg, Set, Array, Interval (and could be to others too).
Yesterday I got a really nice presentation of Miro by alain plantec and he is also using traits.
Stef
On Oct 6, 2008, at 3:35 AM, Bill Schwab wrote:
Stef,
Dumb question: are traits essential to it, or simply a way of achieving it? Just curious, as I am still trying to put traits in perspective. They strike me (so far, right or wrong) as a form of multiple inheritance, which I have assumed (right or wrong) is often not needed with clever aggregation/composition of single-inheritance objects. One very slick use of multiple inheritance in C++ provides an easy way to implement COM objects with multiple interfaces - not that I have any desire to do that, but it is slick for C++. Whether that says something about multiple inheritance's strengths or about C++'s weaknesses, I'm not sure :)
Pearls of wisdom will be eagerly assimilated.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
stephane.ducasse@inria.fr 10/05/08 5:37 PM >>> Hi guys
I did a fun coding session in the train to brest. I started to code collection tests as traits (as damien did for stream) and this is reallllly cool.
I could write some tests and apply them to OrderedCollection, Set, Bag, Interval..... I will publish that and continue. I imagine that the coverage for Collection is increase a lot.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project