IMHO, I think that having dispatch like this would be cool. But…
Issues:
It would have to be optional. Each parameter could be either a var (as
it is now) or a class and var pair to specify specialization.
Making it efficient could be difficult. It could potentially affect the
speed of all method lookups because a method call would have to get the
types of the arguments and try and find a matching method. If it can’t find
one it would presumably use the totally generic case.
Example:
def a_method( a, b, c ) #generic case
…
end
def a_method( String a, Fixnum b, Fixnum c ) #specialized case
…
end
a_method( “hello”, 10, 20 ) #calls specialized case above
a_method( 10, “hello”, “there” ) #can’t find specialized for
(Fixnum,String,String) so defaults to generic.
Bignum and Fixnum. Conversion between these are automatic. How does
this affect specialization?
Wednesday, September 25, 2002, 2:02:37 PM, you wrote:
It would have to be optional. Each parameter could be either a var (as
it is now) or a class and var pair to specify specialization.
not class, but any expression - we can use === to test
Making it efficient could be difficult. It could potentially affect the
speed of all method lookups because a method call would have to get the
types of the arguments and try and find a matching method. If it can’t find
one it would presumably use the totally generic case.
no. if the method definition don’t use type specifiers, this method is
not overloaded. as with overload.rb
Bignum and Fixnum. Conversion between these are automatic. How does
this affect specialization?
def a_method( Integer a)
end
def b_method( Numeric a)
end
···
now i can use overload library and write code such as:
def do_overload(i, s, f)
end
overload(:do_overload, Fixnum, String, Float)
def do_overload(s, i, *a)
end
overload(:do_overload, String, Fixnum)
all that i want - just the same (terrible, you are right) semantics
with a bit more clear syntax and including this feature into ruby
distribution:
def do_overload(Fixnum i, String s, Float f)
end
def do_overload(String s, Fixnum i, *a)
end
although this don’t correspond to dynamic spirit of language, in real
world this adds lot of points to ease of use and even robustness of
language
IMHO, I think that having dispatch like this would be cool. But…
Issues:
It would have to be optional. Each parameter could be either a var (as
it is now) or a class and var pair to specify specialization.
Making it efficient could be difficult. It could potentially affect the
speed of all method lookups because a method call would have to get the
This is not necessarily true - You could make the
the overridden arguments part explicit. For example
we might write
f(i, am , a, the overridden, part ; rest, of, the, *arguments )
…
Example:
Bignum and Fixnum. Conversion between these are automatic. How does
this affect specialization?
As much as I like to argue with Guy over over overloading;-)
I agree with him that mixing automatic conversion and
overloading is a very bad idea (so bad that rather not have
any overloading at all)
not class, but any expression - we can use === to test
Of course. Cool.
def a_method( Integer a)
end
def b_method( Numeric a)
end
Yes, I thought of this. This means however that the lookup needs to work
with class hierarchies:
a_method( 10 ) # parameter is a Fixnum object
Lookup for a_method with a Fixnum find a match. So the call has to navigate
the Fixnum hierarchy to try and find a match. This gets slower/harder with
multiple arguments.
no. if the method definition don’t use type specifiers, this method is
not overloaded. as with overload.rb
Ok, but how does the runtime know wether a method call is overloaded at the
point of call? It doesn’t. It would have to work out the argument classes
and perform a lookup based on them. For most method calls it wouldn’t find
a specialized version and would have to call the generic method instead.
Wednesday, September 25, 2002, 2:02:37 PM, you wrote:
It would have to be optional. Each parameter could be either a var
(as
it is now) or a class and var pair to specify specialization.
not class, but any expression - we can use === to test
Making it efficient could be difficult. It could potentially
affect the
speed of all method lookups because a method call would have to get
the
types of the arguments and try and find a matching method. If it
can’t find
one it would presumably use the totally generic case.
no. if the method definition don’t use type specifiers, this method is
not overloaded. as with overload.rb
Bignum and Fixnum. Conversion between these are automatic. How
does
this affect specialization?
def a_method( Integer a)
end
def b_method( Numeric a)
end
now i can use overload library and write code such as:
def do_overload(i, s, f)
end
overload(:do_overload, Fixnum, String, Float)
def do_overload(s, i, *a)
end
overload(:do_overload, String, Fixnum)
all that i want - just the same (terrible, you are right) semantics
with a bit more clear syntax and including this feature into ruby
distribution:
def do_overload(Fixnum i, String s, Float f)
end
def do_overload(String s, Fixnum i, *a)
end
although this don’t correspond to dynamic spirit of language, in real
world this adds lot of points to ease of use and even robustness of
language
Wednesday, September 25, 2002, 11:23:30 PM, you wrote:
This is not necessarily true - You could make the
the overridden arguments part explicit. For example
we might write
f(i, am , a, the overridden, part ; rest, of, the, *arguments )
no, using at least one type (pattern) specifier will be sign that
function is overloaded. this type can be Object
Bignum and Fixnum. Conversion between these are automatic. How does
this affect specialization?
As much as I like to argue with Guy over over overloading;-)
I agree with him that mixing automatic conversion and
overloading is a very bad idea (so bad that rather not have
any overloading at all)
ruby don’t have autoconversion between these two or any other types. i
think, he just say that fixnum+fixnum can be fixnum or bignum, but
it’s not autoconversion. and i never say about autoconversion for
overloaded functions
does this as well. It short circuits much of the power of
the language to allow people to use ideas they are comfortable
with. It destroys much of the flexibilty of the language.
If you really think you need those chains then you should
be using another language.
As I stated in a previous post this method overloading is
nothing but strict type checking in disguise. IHMO, one
of the whole points of ruby is to get beyond the limitations
of type checking and start to think in different and more
powerful ways. You lose much of the inherent power of
objects when you tie them down with type checking.
Some thing that I would like to see more support for is
the idea of Interfaces from Objective C. This is a kind
of contract of methods that you support. Modules and
the kind_of? method sort of support this, but not in
a very straightforward way. Also, I think much of the
demand for various kinds of “typed” Ruby could really
be satisfied by rethinking the structure of error objects.
Of course, we want to discriminate on the basis of the supported methods
and not depending on the types. As Ruby is dynamically typed we tend to
think that the type of an object is the set of methods it responds to,
which is why classes don’t really work w/ this kind of overloading.
One foolish way I can think of would be the following:
def do_foo<sort,bar>(b)
used when b can respond to sort and bar
end
def do_foo(b)
when it has method each
end
There’s a lot of reasons why it wouldn’t work. And it’s all sugar,
anyway.
···
On Fri, Sep 27, 2002 at 05:16:38AM +0900, bbense+comp.lang.ruby.Sep.26.02@telemark.stanford.edu wrote:
As I stated in a previous post this method overloading is
nothing but strict type checking in disguise. IHMO, one
of the whole points of ruby is to get beyond the limitations
of type checking and start to think in different and more
powerful ways. You lose much of the inherent power of
objects when you tie them down with type checking.
