On Sat, May 24, 2014 at 01:38:54PM -0700, tim Rowledge wrote:
> 
> On 22-05-2014, at 3:47 PM, tim Rowledge <tim at rowledge.org> wrote:
> > It?s something to do with SoundService default etc.
> 
> I?m still trying to puzzle out why on earth we ended up with the system beep being involved in a complex services regime. The beep is supposed to be a trivially simple way to get a noise out of the system when you need to have some alert that doesn?t rely upon anything complex. That?s why it is a primitive; that way if you need something more complex because a noise isn?t appropriate (or possible?) you can make it flash a light or set off some dynamite, or (rather mundanely) write to a console.
> 
> Did anyone come up with an especially good reason for the complication? I?m willing to be persuaded if there is a good argument.
> 

It is certainly reasonable for Beeper to make use of higher level sound services
where available, and fall back on a simple primitiveBeep otherwise. It might or
might not be reasonable for those higher level sound services to invoke user
interaction.

What is definitely not reasonable is to have that complexity be invoked from the
low space watcher.

So we have Beeper class>>beep, which attempts to do beeping in the best possible
way, and we have Beeper class>>primitiveBeep, which just makes some noise without
all the rest of that fancy stuff.

The low space watcher calls #beep. Maybe it should just call #primitiveBeep instead?

Dave