> About minor changes, I haven't decided about most of them (yet most of
> my ideas listed in ToDo list).  It's up to you (i.e. community).
> Let's discuss what you want to see in the future.

Don't know about minor, but a couple of feature I've been thinking about...

First feature: Overloading based on number of arguments

I fully understand and embrace (and love) the typeless nature of Ruby, and
the fact that method overloading based on type is not possible due to it. I
seem to keep running into instances where I'd like to overload based on
number of arguments, though. Currently there are several things that can get
you close, including:

	* methods with different names
	* default values
	* variable length arguments
	* keyword arguments?

It isn't that these things won't work, but each one feels inelegant in
certain situations. I'll deal with them in order. The first one is fine if
the two methods do different things, but if their behavior is basically the
same and only their arguments are different, I'd like to use the same name.
The second one is great as long as it's the last argument(s) that you want
to leave out, but if 'natural argument ordering' (i.e. I like it better at
the beginning :) puts the optional argument at the beginning, no such luck.
The third solution works, but it clutters up my code with a lot of argument
processing stuff.

As far as keyword arguments go, I don't know if we'll be able to re-order
arguments if we use keywords. If yes, then they'll work OK, but there is
still the issue that with a frequently used function it requires the entry
of the keyword every time.

I guess I feel that being able to overload based on number of arguments
would increase the raw clarity, elegance, and forthrightness of my code.

OTOH, there are definitely ambiguity issues (regarding variable length
arguments), as well as the fact that it requires you to know the number of
arguments in order to re-def a method later on (to avoid just overloading
it). It could also be (mis|over)used, but that's true to some extent with
any feature.

So my questions for this one are:
1. Is it at all feasible?
2. What are the reprecussions?
3. Does it add enough benefit to do it?
4. Does anyone else find themselves wanting to do this?


Second feature: Ability to override method creation

I was thinking about the previous feature, and naively thought that I might
be able to implement it myself, perhaps as a mixin. What I wanted to be able
to do was something like this:

def MyClass
	include NumberOverloadable

	def method
		puts("No arguments")
	end
	def method(argument1)
		puts("One argument")
	end
	def method(argument1, argument2)
		puts("Two arguments")
	end
end

The module NumberOverloadable would trap the method definition and if the
method was already defined, would first check to see if the method should be
overloaded, and if yes, it would transparently build a dispatching method,
so you would end up with:

MyClass.public_instance_methods => ["method", "_method0", "_method1",
"_method2"]

where "method" would take in variable arguments and then dispatch to the
proper "_method{x}".

The only problem is, it doesn't look like there is a way to trap the
definition of a method, and I also can't seem to find a way to define a
method dynamically. It seems that this is a 'special' thing in Ruby, as
opposed to just another operation on an object. My (probably naive) feature
request is to make defining a method just an operation on a Module, as
opposed to a 'special' behavior that can't be modified/overridden.

So,
1. Is it feasible?
2. Is it desirable?


Just ideas... I'm curious to hear everybody else's thoughts on them.


Nathaniel

<:((><
+ - -						+ - -
| RoleModel Software, Inc. &		| EQUIP VI
| The XP Software Studio(TM)		|