ducasse <ducasse at iam.unibe.ch> wrote:
> > Well, I think I improved it. If we originally wanted to avoid having
> > class Beeper "act as a global" then IMHO we should never have 
> > introduced
> > Beeper class>>beep. But IMHO I think "Beeper beep" is much better than
> > "Beeper default beep" so... so be it.
> exactly
> but what we always wanted to avoid is to have class whose instance side 
> is empty and having
> only code on the class side. This is not about class not acting as 
> global because I agree with you
> global are not really good because you get two entries on the same 
> stuff.

Ok, I am not sure what this means for my current proposal. It does have
the #play method on the instance side, but that's it. On the other hand
- I can't see why it should have more.

> > Squeak style sidenote: Really can't see the great harm in having 
> > classes
> > "act as globals". They do it all the time anyway. What *is* confusing
> > though is IMHO (repeat IMHO) globals holding an instance of a class 
> > with
> > another name. Like Processor or Transcript.
> >
> >> There are so much stuff to improve in squeak that that the ones 
> >> working
> >> well do not really have
> >> to be the place of our energy.
> >
> > Obviously you haven't looked at the changeset. This is NOT about
> > improving the silly Beeper thing - it is about making the sound package
> > separated from the rest of Squeak. It just *happened* to involve Beeper
> > - and when I see confusing code then I grab it by the balls and try to
> > fix it.
> 
> I looked at it and I understood what you were doing. Still Beeper is a 
> no brainer.

Well, sure - it wasn't much code in it. But calling it a no-brainer
implies I should have understood it fully from scratch which I did not.
I understood the *code* - but not the *intentions*.

Anyway, enough of that. Unless I hear otherwise I am pushing this in.

> stef

regards, Göran