Traits approaching mainstream Squeak
Dean_Swan at Mitel.COM
Dean_Swan at Mitel.COM
Wed Aug 31 00:21:28 UTC 2005
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).
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.
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.
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.
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++.
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.
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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050830/df2ffd97/attachment.htm
More information about the Squeak-dev
mailing list
|