And why it is a AppRegistry. AppRegistry
associates some application, tool. It is very confusing to use it for
a sound provider.
More the name of AppRegistry being confusing, what it does is provide infrastructure for registering providers of a service, and switching which is currently in use.
In other words, SoundService (due to being an ApprRegistry) can switch between using multiple SoundSystems.
Would it make sense to rename AppRegistry to ServiceRegistry therefore?
�
� Then I do not understand why it is named
AbstractSoundSystem and not simply SoundSystem (remember
AbstractString).
Yes let us clean all that :)
Can you take the lead on that?
We could include the sound package in the release.
Because AbstractSoundSystem provides the common interface that is expected to be supported by a given entry in the SoundService providers . Whether that warrants including Abstract in the name is debatable I guess :)
On Sat, Nov 17, 2012 at 9:33 PM, St�phane Ducasse
<stephane.ducasse@inria.fr> wrote:
Hi pavel
In fact the registration default sound system is broken and we should fix it.
I forgot what is the problem :)
Hi,
I would like to discuss the Beeper class a little bit. The main
purpose of this class is to provide Beeper beep message and use
SoundService with respect to current sound enabled settings or VM
implemented primitive for beeping.
Yes this was the idea and to remove it from smalltalk.
Outright removal is a bit harsh considering what external users may exist.
It probably deserves either being put in a deprecated package, or moved to a loadable compat package.
Cheers,
Henry