[ENH] SoundSystemCleanup-gk ( [er][et] needs a little work )

ducasse ducasse at iam.unibe.ch
Tue Feb 24 08:40:43 UTC 2004


Noury if you have time and energy to reply please do because I do not 
have time for that.

Stef


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.

yes so fix it.

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



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

Ok no problem for me.
I spent already too much time in the past on that. So this is perfect 
for me.

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

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.

stef




More information about the Squeak-dev mailing list