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