From: Christoph <chr_news@...>
Date: 2002-09-10T12:13:11+09:00
Subject: Re: Larry Wall's comments on Ruby

"Marcin 'Qrczak' Kowalczyk" wrote in
 ...
> The problem is that Ruby couples the syntax of the call with the way
> the function is dispatched.
>
> The distinction between "intrinsic behavior" and "external function" is
> fuzzy. Why are trigonometric functions more external than arithmetic?
> What about exp, sqrt and abs?

The artificial distinction,  mathematically it makes little (actually
no)  sense (so why should Ruby do it?)  between external and
intrinsic Ruby functions is more easily defendable in a language
like  Python, where ``self''  needs to be an explicitly method
argument and  would not be an implicitly supplied argument of
every Ruby method call.
I hope that once Ruby gets proper namespace support we will
also see the end of the Java'ish module function Math.cos
and it friends.

>
> If a function should be implemented differently based on types
> of arguments, the Ruby way is to make it a method of one of the
> dispatched arguments (and it fails to provide means to dispatch on
> several arguments). Mathematical functions above should be dispatched
> (some even on several arguments), so basing on this principle they
> should be methods of numbers.
>
> It makes the notation unfamiliar - that's how Ruby's syntax looks
> like. These method calls could be wrapped in functions like module
> Math currently.
>
> A problem in making all functions methods of the class of their most
> important argument is IMHO the largest flaw in Ruby: that all method
> names of the given class are put in a single namespace! And class
> names generally too.
>
> I know that it would otherwise not fit the way method calls are
> designed. This is a reason why I'm not a fan of the model.

I agree with you whole heartedly , expect that it really isn't a failing of
Ruby itself but the single method receiver model Matz and probably
the vast majority of  ``Rubyists''  (imo unfortunately) seem to prefer.


/Christoph