--- Russell Penney <russell.penney at tincanct.com>
wrote:
> Richard,
> 	I really like this idea, to me it satisfies the
> basic unease I
> had with beep.
> I just had a look and of the 150 or so senders of
> beep, about 50% are
> from Morphs which override beep anyway so they are
> not a problem. Some
> of the others use Smalltalk beep anyway. So it
> wouldn't be a major
> problem to do.
> 
> I sort of picked on beep as an example of what I saw
> as a serious
> problem which has resulted in the KCP and MCP
> projects. I remember
> reading a Smalltalk design type book ages ago (I
> will see if I can dig
> up name and author when I get back from Korea) which
> said that if you
> need to put a method in Object, think again, and
> think some more and if
> there is no other way, sure do it. 
> For example, imagine you are not a 20 year veteran
> of Smalltalk or
> coding, look at Object, and see that there is 'beep'
> and 'beep:'. Each
> uses a completely different way of playing sound but
> they are named the
> same! That is confusing for the poor bunny who
> doesn't know Squeak very
> well.

Well, I don't think the ST-80 beep was there to
produce "sounds" !  It's just a convenient place to
put such an utility method and I guess in 99% of the
cases, #beep is used for debugging or used in such a
way that we don't care about the sound it makes as
long as it makes a beep!

In such a case, shouldn't we also move #-> and
inspect, after all we should use
Association>>#key:value: and 
Inspector>>#openOn:.  Too complicated?  I guess that's
why their "shortcuts" were introduced in Object, just
like #beep...  It's just more convenient...  and
doesn't necessitate any "manual conversion" when
porting from <any other Smalltalk> since #beep has
always been in Object since then world knows how to
evaluate "3+4" ...

=====
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero. -- Albert Einstein