Hi Russel,

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

Good luck trying to remember this ;-) I think #beep is a good name because
it has connotations from terminals (BEL character etc) and most people who
will have to deal with it (not that many nowadays) will probably have
similar associations. It also provides an implementation hint as to what a
good thing to implement that method would be.

> 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 many cases, I would. Having a polymorphic response in Object (with
appropriate comments of course, ho-hum) helps me to see what a method can be
used for. In particular for newcomers it can be helpful to state what one
can potentially do here. (not that I think this is really that important for
#beep)

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

Agreed. This was just pointing out that there can be a number of reasons for
having a 'utilitiy' method in Object. With the point being that minimalism
isn't the only worthwhile goal to strive for. Small is good, and smaller is
better. But absolutely minimal sucks big time (or else we'd be using
assembler ;-)

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

Yes. But I got the impression that your point of view was somewhat along the
lines of "if in doubt err on the side of minimalism" and in many cases I
don't agree with that.

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

Good design implies providing the right level of convenience - this is where
a lot of reuse comes from. So that good design and minimalism can be quite
opposite goals.

Cheers,
  - Andreas