ducasse <ducasse at iam.unibe.ch> wrote:
> > Yes, as I interpret it the use of play is to be able to install another
> > "playable" as default beep.
> 
> Yes!!!

You don't have to be so aggressive, I was merely explaining it.

> Really I have no time now to discuss again that. This was sent 
> loooonnggg time ago
> and people were aksed for review. So why now again.

Well, I will tell you exactly why:

Because I am now integrating the SoundSystem changesets that Adam has
written and it affects all this. Ok?

> >>> Back on the subject of Beeper>>beepPrimtive:  Why even have this
> >>> method?
> >>>  Consider Beeper class>>beepPrimitive private and use it directly in
> >>> any
> >>> places that the methods of Beeper need to generate a beep directly.
> >
> > I agree - I was also puzzled over the instance side #beep and
> > #beepPrimitive. They just muddled the concept IMHO. I think I will
> > remove those - #play is fine by itself I think.
> 
> I'm tired.......

Tough for you.

> because if we want to be able to change the default beep as explain in 
> the comment
> we want the instance side to be able to accept the same method than the 
> class.

The comment says no such thing - and I really can't see why the instance
side needs to accept the same messages that the class side.

It explains that it uses a #play message that it sends to the registered
"playable entity". And it also clearly registers an instance of itself
as the default playable entity. All fine so far.

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.

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 sure don't get it - why would the newbies?

> This way we have the same protocol and people get used to have Beeper 
> beep

Still can't see the argument.

My firm suggestion is to make this much simpler:

- Only have #play on the instance side. Also explain in the class
comment that an instance of Beeper is the default playable entity. I
just rewrote the class comment with this and other improvements.

- Only have #beep and #beepPrimitive on the class side thus not
ecouraging people to write stuff like "Beeper play" etc.

- Proper method comments explaining why people should use #beep instead
of #beepPrimitive. I have added this.

Furthermore if you look at the code I have submitted it modified
Beeper>>play to be:

	SoundService default beep

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

regards, Göran