Dean,

>From what I've seen the last couple of weeks, there are several other
factors in the Traits decision. From what Stephane Ducasse has reiterated a
couple of times, that project requires that they need: (Squeak to)

[quote]
- In all cases we need a stabler Parser, cleaner AST, ClassBuilder, and
BROWSER.
So we will see if we can get some momentum and synergy with SqScript, in
such a case
we will see if we use SmaCC, redo ClassBuilder. Else we may end up moving to
another Smalltalk.
[/quote]

Don't know about you, but I've never seen a tree those things grow on. We've
seen the part about Ducasse threatening to switch to another Smalltalk a
couple of times if somehow Squeak doesn't comply. [We both know it cannot;
the above are cross purpose with the current 'rip the image apart' stuff
going on which will probably take several months. It would not make sense to
rip the image apart and introduce potentially unstable underpinnings both at
the same time. Unless I miss my guess, the introduction of new code into the
image other than bug fixes or relatively simple reorgs will probably not
happen in the near future]

>From the tone of the emails, it has sounded like someone has been holding
these things back, keeping these prerequisites for the Traits project from
being available to Squeak. I haven't been following this thread very
closely, but I would like to know who is responsible for keeping this code
away from us. I don't recall seeing the new browser that Ducasse submitted
for inclusion, is someone hiding it from me?

Thanks,

Jim

PS: I didn't realize my AST was dirty, or that I needed to clean it, but
hey, that's me.

----- Original Message ----- t
From: "Swan, Dean" <Dean_Swan at Mitel.COM>
To: "'The general-purpose Squeak developers list'"
<squeak-dev at lists.squeakfoundation.org>
Sent: Friday, February 14, 2003 7:44 PM
Subject: RE: Two important issues...


> Just to voice my opinion, I agree with Daniel on this.  I feel like I want
somebody to convince me that Traits is something I need.
>
> I don't really understand Traits too well at this point, but I agree with
Daniel that it seems to be of greater value for refactoring existing code
than it is for writing new code.  How is this different from AspectS and
Perspectives, or mix-ins for that matter?  My cursory (and perhaps
incorrect) understanding leads me to believe that Traits is just another
"flavor" of the same kind of thing.
>
> Have there been any costs/benefits analyses done of this kind of system?
While I understand that it allows for a higher degree of reusability, I'm
not convinced (yet) that it's worth the complexity it can add to the
inheritance graph or the greater potential to break more classes faster by
changing a highly reused method at the Trait level.  I understand
subclassing and overriding a method from a superclass.  Traits is more
complex.
>
> Along the same line of thought, I wonder just how much utility can really
be had from Traits?  Would refactoring the Collection hierarchy, for
example, with Traits reduce the number of methods? code space? increase
performance?
>
> I would hate to see Squeak/Smalltalk gain as much "flexibility" as
something like C++.  Will Traits make it any easier to do ill-advised things
(i.e. write bad code)?
>
> Traits strikes me a little like the kind of thing an optimizing compiler
might do "under-the-hood", but it's not clear that this fine grain control
is a "Good Thing"tm at the source level.
>
> I am not saying that Traits should never be a "CORE" package, but IMO it
is  FAR to early for it to even be considered for that yet.  It would
> be very good to see it used for some "real" code (as opposed to examples
contrived to highlight the value of Traits) so we can get a feel for where
the strengths and weaknesses are.
>
> To me, Traits is a much more experimental technology than Anthony's VI4
work (full closures, context stack unwinding, etc.), so I'm a bit wary.
>
> -Dean
>