[ENH] SoundSystemCleanup-gk ( [er][et] needs a little work )
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Tue Feb 24 08:56:46 UTC 2004
ducasse <ducasse at iam.unibe.ch> wrote:
> > 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.
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
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
[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.
> > (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.
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.
More information about the Squeak-dev