On 31 août 05, at 02:21, Dean_Swan at Mitel.COM wrote:

>
> Hi Stéphane,
>
> Yes, I ***really*** do think that the Collection hierarchy is a  
> "toy" example.  Allow me to explain why:
>
> What was done with the Collection hierarchy was essentially a  
> refactoring to use Traits.  It wasn't a new design from  
> requirements.  And while the Collection hierachy is a fabulous and  
> powerful invention, it is really just a bunch of generic components  
> to be used in building more complex systems.
>
> My point was that I don't think that the capabilities Traits offers  
> matches up with the way that commercial software is created in the  
> "real" world.
>
> I work on a product that is built from over ten thousand source  
> files and has hundreds of developers working on it.  The system  
> runs on at least 8 different target CPU's (obviously, not all of  
> the code runs on all eight different CPU types), and includes code  
> written in C, C++, Java, JavaScript, Pascal, various assembly  
> languages, and includes over 300 megabytes of executable code.  I  
> am not commenting on the quality of code, only the quantity here.   
> The quality level of the code by any objective standards varies  
> widely, depending on the skill and experience of the people who  
> worked on it and the other constraints placed on the development  
> (i.e. if we can't demonstrate the new feature to an important  
> customer by the end of the (pick some time interval - quarter,  
> month, week, etc.) we will lose a sale worth millions to an evil  
> competitor).

Did we say that traits will solve all the problems?
Traits support a better factoring of code and reuse within and among  
classes.

>
> I think what I am describing here is how a lot of software gets  
> created in the real world, and in this kind of environment the code  
> never gets past the "make it work" stage.  "It works - ship it, and  
> get on to the next thing" tends to be the approach.  My point is  
> that common behavior that COULD be reused and benefit from Traits  
> is not usually identified until quite late in the game, after a lot  
> of code has already been written, if it can be identified at all.

then?

> The other idea that I was trying to get across is that code reuse  
> is a double-edged sword.  While it can reduce maintenance effort,  
> and improve the overall quality of a code base, it also makes the  
> codebase more brittle by introducing heavily loaded single points  
> of failure.

I do not buy that.
I know a company that duplicated 3 millions of C++ code 15 times and  
they are in trouble.

> So I guess I am raising a largely philosophical issue.  As I  
> understand it, Traits facilitates code reuse in ways that would be  
> difficult if at all possible with a single inheritance class  
> hierarchy.  This capability comes at the cost of an extra layer of  
> complexity (or degree of freedom, if you prefer) and possibly a  
> decrease in performance.  The philosophical questions are how can I  
> use it, and how will I benefit from having used it?
>
> The Collection hierarchy example shows that I can implement 27  
> classes with 48 Traits, saving about 10% in the number of methods.   
> This says to me that there was only an average of 2 or 3 methods  
> per class that were redundant or refactorable  (Given that we end  
> up with 567 methods, this implies 630 methods in the original  
> implementation, so we eliminated about 63 methods).  So, in this  
> respect I don't think that the Collection hierachy is a very strong  
> example for showing the benefits of Traits.  You had my attention  
> more with the RectangleMorph example.  There you were going to save  
> 70 methods with only 3 classes involved.

What can I say?
You can use Smalltalk as it was 20 years ago.
You can also use a trait image without using traits.

> Admittedly, the paper that is dedicated to the Traits based  
> Collection class hierarchy goes into more detail and shows a  
> greater savings in method count, but I am not sure if I agree that  
> counting (m+h) is legitimate, so I will call it 17.7% instead of  
> 28.2%.
>
> I did read the papers, but like many good papers they generate at  
> least as many questions as answers.  Traits is very "blue plane"  
> stuff and therefore interesting, but we've had single inheritance  
> for over thirty years, and most of the world still doesn't take  
> advantage of the capability that it brings.  I approach Traits with  
> trepidation because it offers another way to do things and I do  
> think there is such a thing as too much flexibility.  That was/is  
> one of the major problems with C++.

C++ is not flexible it is complex, complex and complex.

> So I guess I'm still looking for somebody to show me the "good- 
> ness" of Traits, because so far it looks interesting, but like a  
> lot of work for a small increase in code reuse and a (hopefully)  
> small decrease in performance, and we've been seeing a "small"  
> decrease in performance with each successive version of Squeak for  
> way too long now.  This is (of course), only my opinion.  I could  
> certainly be in the minority here.

On my code there is no slowdown since I use accessor anyway.
So the only slowdown you can get is getting an acccessor call instead  
of a direct access for an instance variable.

> Traits shows clear value in refactoring, but refactoring is "code  
> cleaning", and it doesn't happen much in the real world.  In fact,  
> it is sometimes "forbidden" because it is seen as a high risk to  
> touch code that is "field proven".

So what you are saying is that we shoudl not do anything.
So with that state of mind do you think that we would programming in  
OOP today or still in assembly.

> So for now I will sit back, watch, and try to learn something.
>
>                 -Dean
>
>
>
>
> stéphane ducasse <ducasse at iam.unibe.ch>
> Sent by: squeak-dev-bounces at lists.squeakfoundation.org
> 08/30/2005 09:37 AM
> Please respond to The general-purpose Squeak developers list
>
>
>         To:        The general-purpose Squeak developers list  
> <squeak-dev at lists.squeakfoundation.org>
>         cc:
>         Subject:        Re: Traits approaching mainstream Squeak
>
>
>
> Hi dean
>
> do you ***really*** think that the Collection hierarchy is a toy
> example....
> I'm not sure that we are talking about the same.
>
> On 30 août 05, at 02:28, Dean_Swan at Mitel.COM wrote:
>
> >
> > While I find all this discussion fascinating, I would like to share
> > a few thoughts on the idea of including Traits in mainstream Squeak.
> >
> > My first concern is performance.  Since Traits carry no state, they
> > will need to use accessor methods and message sends are clearly
> > much slower than direct instance variable access.
> >
> > My second concern is regarding how Traits should/could/would be
> > used.  All of the examples that I have seen so far, including the
> > refactoring of the Collection hierarchy, seem to me to be "toy"
> > problems.  I would be interested to read about non-trivial cases
> > where Traits would solve a significant real world problem.
> >
> > It would seem to me that the kind of reuse that Traits enables is
> > the kind that isn't apparent at design time, since individual
> > classes of object are usually designed separately and often by
> > completely different people.  The common behavior and opportunity
> > for code reuse might only become apparent after the initial design
> > is implemented.  It has been my experience that once something is
> > implemented and working, unless there is a compelling reason to
> > justify it, the code is never revisited.  Management is generally
> > focused on allocating resources to things that will yield either an
> > opportunity for increased revenues, or reduced costs, and code
> > "cleaning" is rarely viewed as either.  If it ever gets done (code
> > cleaning), it is usually silently piggybacked on required bug fixes
> > by individual developers who feel it is important.  Am I in the
> > minority here, or is this how commercial software development works
> > in general?
>
>
> Cleaning your design does not solve the problem that traits solve.
> Read the papers. Sometimes we are forced to duplicate code or to
> write a lot of delegate methods just because we cannot simply reuse
> method dictionary. This is what traits are about.
>
> > I would even suggest that single inheritance doesn't get used that
> > much in practice.  I see an awful lot of C++ where classes are root
> > classes and implement a singleton object.  I see poly-morphism used
> > a lot, but not much inheritance.  I also see STL used a lot to get
> > common syntax container objects, that you get with the standard
> > Smalltalk Collection hierarchy anyway.
> >
> > So I guess I don't see what Traits gets us that we can't already do
> > in Squeak with some judicious use of proxies, DNU and separate
> > "behavior only" and "state only" classes using accessors for all
> > instance variable access.  Is the real benefit in having tools that
> > formalize this and make it easy?
> >
> > Is Traits implemented by just pointing a class's method dictionary
> > entries to the approprate seemingly class-less compiled method
> > defined in a Trait?
> >
> > I guess I don't fundamentally oppose including Traits in mainstream
> > Squeak, as long as it's still possible to ignore it and it doesn't
> > cause a decrease in performance for commonly used objects (i.e. the
> > Collection hierarchy).  From what I've read in the whitepapers, it
> > seems it should be safe and easy to ignore, so the only question I
> > guess would be performance.
> >
> > And lastly I will just say that as others (Andreas) have pointed
> > out, maximising code reuse is not always desirable.  I can see the
> > argument in favor of code re-use to propagate common behavior
> > without having to find every duplicated variation, but there is
> > also the other side of the argument where a single bug in a common,
> > highly reused method can cause a lot of things to break that might
> > otherwise work properly.
> >
> >                 -Dean
> >
> >
>
>
>
>