Hi Andreas,

> > Why is beep in Object at all? All the objects in Squeak
> don't need to
> > know how to beep. The sound system needs to know how to beep.
> 
> No. The *system* needs to know how to beep. The sound system
> knows how to play elaborate sounds but the system may - in 
> the absence of full sound and/or display support - still need 
> to have a way to provide user feedback. #beep really has 
> nothing to do with sound (what kind of music is beeping?) so 
> what it really does is either to raise the user's attention 
> or alternatively to indicate progress. Here, #beep is among 
> the lowest levels of support which is why I would put it 
> either into Smalltalk or Object. And the latter mostly 
> because it means less places to touch. But #beep has nothing 
> to do with sound whatsoever - it might actually be 
> implemented in ways which aren't even aural.

Fair call but I think you have just answered my point about object
design :-) I keep reading that the method name should detail what the
method does (as far as that is possible). beep seems to be the wrong
thing to call this especially as you say it may not even be aural. Maybe
"progressFeedback" or "iJustWantedToTellYouIAmStillWorking" or something
:-)

> > It seems to me that this is the reason Squeak is spaghetti
> code in the
> > first place, people aren't sure where to put something so
> it goes in
> > object and now us newbies cant find anything or figure out what to
> > use. Plus you are teaching us bad object design habits! :-)
> 
> No, not really. Let's assume I have a headless system which
> has a (limited) kind of sound support. Implementing #beep in 
> Object I can have various implementations of #beep which all 
> sound differently. So that (for example) I can use the sound 
> for debugging (this is no theoretical example - I have done 
> exactly this in the past and since it was in C it was a real 
> PITA). Using Whatever>>beep does not even give you the chance 
> to provide polymorphic responses to such messages.

Very good point, I hadn't thought of that use (even though I too have
done that in C, yuk). However in that case I would implement my own
method because it was in my application and my domain. I may put it in
Object for ease of use. I would not expect the kernel to have that
functionality.

> In addition, it can be much more intent-revealing if you know
> *who* you are asking to do something. For example, 
> Object>>error: is not required either (you could do the same
> with Utilities>>error:) but still it's typically a specific
> object which we think has a problem so that anything but 
> 'self error' is very revealing indeed.

'self error' is revealing, yes, I just don't believe 'self beep' is,
especially when a 'beep' may write something to a log file. I think this
is confusing to the plebians like myself.

> 
> > Andreas you commented in AbstractSound "beep in the presence of the
> > sound system. this method may still #primitiveBeep if sound	support
> > is disabled or doesn't work or whatever". So use that please don't 
> > clog up Object with methods that aren't required.
> 
> What is "required" depends heavily on what you're doing.
> Object>> -> isn't required either but I still haven't seen
> anyone asking to remove it. There is a fine difference
> between "required" and "useful".

I agree. However think about this, maybe during the refactoring of the
KCP and MCP Object>> -> could be refactored somewhere else, does that
mean that it shouldn't because it's useful even if it does make more
sense? There is a fine line between good object design and spagetti too.

I guess it is my opinion that the kernel especially should be
minimalist, well designed and streamlined so that people have ability to
realise all the disparate visions. As I said above maybe just a name
change would make this better.

Russell