ducasse <ducasse at iam.unibe.ch> wrote:
[SNIP]
> > But it does not say why Beeper also implements #beep and 
> > #beepPrimitive,
> > and it also doesn't clearly say why the class side implements #play.
> > IMHO having all these three on both sides just makes this overly 
> > complex
> > and confusing.
> 
> yes so fix it.

Already done.

> > Is the Beeper class intended to be used as a playable entity (since
> > there is a Beeper class>>play)? Is a beeper instance to be used for
> > beeping (since there is a Beeper>>beep)? Is this to encourage "Beeper
> > default beep" to work as well as "Beeper beep"?
> 
> I do not know read the other email I sent. Beeper beep is a convenience 
> to avoid to write
> Beeper default beep. because one idea was to avoid as much as possible 
> to have
> class acting as global. Because now if a newbie read the class he will 
> see that there is a
> default instance so we need instance behavior. and if you have time to 
> spend on it
> and want to improve it, improve it.

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.

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.

> I want to focus on more important 
> stuff and thing
> that we already spend too much time on that in the KCP thread long time 
> ago.

I thought I explained this: I am integrating something important - the
Cleanup.sar from Adam. It has a larger refactoring regarding sound using
the AppRegistry pattern so that we later can cleanly rip out the whole
Sound package. And since his classes handles #beep etc I needed to
integrate this with Beeper *no matter what you feel about it*.

So if you don't have time to help me with this - then don't reply.
Simple as that.

> 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.

[SNIP of short explanation of what I have done]
> Ok no problem for me.
> I spent already too much time in the past on that. So this is perfect 
> for me.

Great.

> > (I renamed SoundSystem to SoundService - and no, I will not discuss the
> > naming at this point :)
> >
> >> stef
> >
> > Anyway, I am slightly annoyed at this - perhaps you can tell from my
> > tone. I am working to get this right so that this rather large
> > enhancement can get in before alpha is over, and I am writing comments
> > to code that other people have written.
> >
> > Thus I am not in the mood for anything else than factual, calm
> > reasoning. Give me that, or give me none.
> 
> you are right but I do not have time for that item sorry. I have no 
> time, no time, no time for beeper.

Then fine - stop replying. Do something more important.

> I guess that noury does not have even the time to read the mailing-list 
> so do whatever you think is cool
> and sorry for my tone. But I'm losing my time there.

It is NOT my fault - you hit your reply button all by yourself.

> stef

regards, Göran

PS. Grrr. .........deep breath. Ok. Done. Happy again. :)
I like you Steph, no worries, really. Sorry if I blasted off too much.
And I also deeply appreciate all your work as a harvester and KCP etc,
just so you know. This time we just ended up off base.