This runs squarely against a prominent argument of the anti multi-method camp'' that Ruby's open classes’’
(a very descriptive term btw.) somehow reduce the need
of method overloading.
Well expect that you forget that
Maybe this is also a good time to mention that the ``problems’’
you foresaw when playing around with your own overloading
implementation was imo caused by the fact that you allowed
modules (such as Enumerable) as (multi-)method signature types.
Had you only allowed genuine classes as signature types, you
probably would not have run into any major (non-performance)
problem.
Maybe this is also a good time to mention that the ``problems''
you foresaw when playing around with your own overloading
implementation was imo caused by the fact that you allowed
modules (such as Enumerable) as (multi-)method signature types.
No, no. I've just added modules to kill it
Another example, what do you expect with ?
ruby -e 'class A < Array; end; a = A.new; b = A.new; p ((a+b).type)'
Well you would (better finally could) get ride of
coercion …
In this case, just change the name of the language
I grant you that overloading might change the language
for good or maybe bad? However getting ride of
coercion is no lose - coercion is complicated, slow,
and it is almost trivial to make mistakes …
ruby -e ‘class A < Array; end; a = A.new; b = A.new; p ((a+b).type)’
I would bet on an A object. This behavior is somewhat problematic
(see the old “Subrange of String subclass” thread) but I don’t see
this as a problem of overloading.
Anyway I don’t think that ``general method overloading’', with
the possible exception of operators, is a good idea anyway.
Rather, the request of an ``overloaded method call’’ should be
made explicit - as in
``proc type’’ class_eval’s do not change the scope. In other
words there is only one (the top) Beast around - hence
This must have changed from 1.6 to 1.7.
/ test.rb
Beast = self
(@temptation = Class.new String).class_eval <<-Body
Beast = self
def six_six_six; Beast end
Body
t = @temptation.new("foo")
p t.six_six_six
p Beast
Beast = self
(@temptation = Class.new String).class_eval do
Beast = self
def six_six_six; Beast end
end
t = @temptation.new("foo")
p t.six_six_six
p Beast
A ``string type’’ class_eval creates the expected two
Beasts and six_sx_six picks up the inner Beast - hence
I guess the string-type eval will work on both 1.6 and 1.7. I wonder if
there’s a way to get the same functionality on both 1.6 and 1.7 without
evaling a string.
Paul
···
On Fri, Sep 20, 2002 at 07:38:40AM +0900, Christoph wrote:
ruby -e 'class A < Array; end; a = A.new; b = A.new; p ((a+b).type)'
I would bet on an A object. This behavior is somewhat problematic
(see the old "Subrange of String subclass" thread) but I don't see
this as a problem of overloading.
If you add overloading, you add implicitely a new rule : to resolve a call
ruby compare 2 classes and select the *best* choice.
This is not the choice made by ruby in my example because its result is
Array
In short :
* you have removed coercion
* you change one rule of ruby
It's time, for you, to find a name for this new language (try to avoid P
for the first letter :-))
I would bet on an A object. This behavior is somewhat problematic
(see the old “Subrange of String subclass” thread) but I don’t see
this as a problem of overloading.
If you add overloading, you add implicitely a new rule : to resolve a call
ruby compare 2 classes and select the best choice.
I was not writing about my own preferences, just expectations,
(I strongly prefer ``Array’’ btw.) based on the imo wrong headed
type mutating behavior (no Ruby in side at the moment)
p A.new.sort, A.flatten, … # A, A, …
This is not the choice made by ruby in my example because its result is
Array
In short :
you have removed coercion
not a big loss;-)
you change one rule of ruby
I guess, adding overloading would be a much bigger
change …
It’s time, for you, to find a name for this new language (try to avoid P
for the first letter :-))
