From: Marcin 'Qrczak' Kowalczyk Date: 2002-09-10T07:01:58+09:00 Subject: Re: Larry Wall's comments on Ruby Mon, 9 Sep 2002 14:26:37 +0900, Wirianto Djunaidi pisze: > Totally agree. It's the same case as with the 5.cos > doesn't make sense because cos(), sin(), etc..are not > behaviour of a number in regular sense. Those are > trigonometry functions which applied on those numbers. 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? 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. For me names defined in a module (i.e. file) should by default be local to this module. When several modules independently define the same name (function or class), even at their top levels, they should not conflict. And the natural place to put functions should distinguish functions defined by independent modules. In Ruby the place is the class of the most important argument and the name must be unique within a class... Types can be dynamic; scopes should be static. When I refer to the name of an operation, dispatched or not, it should be explicitly imported from somewhere or introduced locally, not pulled from some global namespace - so names can be given without worrying about conflicts with other modules. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/