Hi Göran and all

> ... and if we hurry up we might be able to get this included
> in 3.9 or else it will be in 4.0 - but that doesn't really 
> matter, now does it? Because the above steps seems something 
> we *do* need to do.
> 
> Ok, just a suggestion - how does that sound? Stef? Nathanael?

I fully agree with you. It's very important to make sure that Traits (as
all the other major tools/improvements) are made available (at least as
a beta) so that the "evaluation crew" (and anyone else who is
interested) can see it and decide whether it should go into the image.

Therefore, I also agree with Goran that following this process is
something we do need to do and if that means that it will postpone it to
Squeak 4.0 rather than 3.9, so be it.

But at the same time, I can also understand Stef's concerns. Pushing
traits ahead means a lot of work for him and his students (such as
Adrian and me ;-). And because traits have a fair amount of dependencies
on the kernel, it requires a lot of work just to keep it compatible with
each new version of Squeak. So, I can really see why he would like to
have it to be in the image as soon as possible.

What makes this worse is that some people really do not understand the
difference between research and improving Squeak for the community
(which we are of course also part of)! When we invented traits three
years ago, this was exciting research and that's why we implemented a
prototype that allowed us to do all the cool experiments that were
necessary from a scientfic point of view. But this is where the research
aspect ended and we could have stopped right there without loosing
anything as far as fun and research is concerned. However, we didn't
because we thought that traits could be a very useful improvement for
the Squeak language and we wanted to make it available to the community.
This is why we went throught the hassle of cleaning the kernel and
implementing a clean version of traits on top of it, even though this
was really "boring engineering work" and was taking away time that we
could spend on cooler stuff!

Regarding all this (and knowing Stef's French spirit ;-), even I (a
"nice" and calm Swiss) can somehow understand that Stef freaks out when
he reads that traits are a "research item" that only serves the purpose
of satisfying the urges of some academics.

As a last point, I would like to say that I somtimes wish that people
would be a bit more open-minded regarding their judgments of
improvements to the Smalltalk language. I think it is very important to
keep in mind that humans have a tendency to idealize what they are used
to, simply because this is what they know.

Cheers,
Nathanael


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of goran.krampe at bluefish.se
> Sent: Donnerstag, 24. Februar 2005 10:49
> To: The general-purpose Squeak developers list
> Subject: Re: Stefs roadmap for 3.9, time to get it nailed down
> 
> 
> Hi fellow Squeakers! (extra cheerful)
> 
> =?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch>
> wrote: [SNIP] 
> > >> We proposed to give a real definition to canUnderstand
> in presence
> > >> of
> > >> abstract method but people having nothing
> > >> to do with squeak started to shout.
> > >>
> > > Hmm... probably missed that one - do you have a pointer
> or at least
> > > approximate time period about this discussion?
> > look for canUnderstand
> > 
> > canUnderstand: is returning true even when there is only self 
> > subclassResponsibility in the body and this is a problem Because if 
> > you send a message after you get an error which
> is not what
> > you want. And traits requirements are expressed
> > as self requirement... So some people shouted and they were
> wrong and
> > that drove us crazy because big mouths were talking as usual.
> 
> I recall that - and I also see the problem. This seems like a
> simple problem to figure out? Was it never resolved? What was 
> the "wrong" opinion? And if people don't want to touch the 
> canUnderstand:, why can't we have another method doing the 
> Right Thing? :)
> 
> Let's resolve this.
> 
> [SNIP]
> > > There must be some time to be able to play with the
> stuff, some time
> > > to build up a real world code base with Traits, to have
> people look at
> > > kernel refactorings with Traits, etcetera.
> > 
> > Exactly 3000% correct. We do not that we never did and we
> do not want
> > to be the guys that fucked up
> > and that 3.9 is a doomed fucked up release by the guys from
> berne. You
> > see what I mean. Also at the conceptual
> > level I want to be able to use Squeak to teach newbie and
> this is why I
> > do not want namespaces. So
> > your points are reasonable and we will work hard to arrive to that
> > point. But now our effort can't be just ok this is just 
> research stuff
> > and this is..m,.m.m
> 
> Right.
> 
> > > All the other good tools that are in the base image have had to go

> > > through the same testing and acceptance process: SqueakMap, 
> > > Monticello, all were available and in use before they
> were made part
> > > of the base image. Traits *must* go through the same
> process, it's to
> > > big to just shove it in. So it's vital to get a production-level
> > > version out there ASAP so people can work with it. That's 
> usually the
> > > best way to let people make up their minds.
> > 
> > Exact!
> > We never said anything else. Reread the 3.9 roadmap all is
> there! We
> > ALREADY say it.
> 
> Ok, then I may have misunderstood it - I felt like it was
> presented as something to decide upon right now. Perhaps we 
> can put it like this
> instead:
> 
> - First you guys make sure there is a beta (or better)
> available for us to play with.
> - Then we... hey, why not simply make a Team that 
> investigates it? Look it over, check the code, try it out, 
> see what newbies and oldtimes stumble on, perhaps refine and 
> document based on that, etc. This work ought to be useful in any case.
> - Go to the stakeholder communities and get their input.
> - After that we either:
> 	1. Decide it is good to go and we want to have it in 
> the Basic official distro.
> 	2. Decide it is good, but based on other feedback we 
> want to have it as an "optional official" package instead. At 
> least for a while. This would mean it isn't in Basic - but we 
> make sure it is presented as a officially community supported 
> package. If you know what I mean.
> 	3. Decide it is bad and it will have to stay as "any package".
> 
> ... and if we hurry up we might be able to get this included
> in 3.9 or else it will be in 4.0 - but that doesn't really 
> matter, now does it? Because the above steps seems something 
> we *do* need to do.
> 
> Ok, just a suggestion - how does that sound? Stef? Nathanael?
> 
> regards, Göran
> 
>