Object methods with same name

[Seth LaForge]

The following may be a misunderstanding of how the generic function
model is used with OOP. If so, let me know what I should be doing
differently.

Suppose I have a class <window>:

define class <window> (<object>)
// Some slots...
end class;

and a method draw which takes an instance of <window> and four
additional arguments:

define method draw (self :: <window>, x1, y1, x2, y2)
// Draw part of a window...
end method;

Now suppose I have an unrelated class, <card-deck>:

define class <card-deck> (<object>)
// Some slots...
end class;

and a method draw on <card-deck> which takes a different number of
arguments than my previous draw:

define method draw (self :: <card-deck>, number-of-cards)
// Draw some cards...
end method;

This is, of course, and error, since all methods of a generic function
must be congruent, which means in this case that they must take the
same number of arguments.

I can get around the problem by defining the above methods to take a
single argument and return a method:

define method draw (self :: <window>)
method (x1, x2, x3, x4)
// Draw a window...
end method;
end method;

define method draw (self :: <card-deck>)
method (number-of-cards)
// Draw some cards...
end method;
end method;

This has the advantages over the previous versions of (1) being
correct; and (2) allowing the more natural access syntax:
a-window.draw (0,0,100,100);

However, it will probably tend to be less efficient, and there is
still potential name collisions, for instance if you decide to have a
method named add for your object, since dylan already defines add...

Am I missing something here? Is there some way to define a method of
some class (using method in the traditional sense of the word) and be
garunteed that there won't be a name collision? I suppose one could
always use explicit names for methods (window-draw and
card-deck-draw), but that's a lot of work...

Seth

[Patrick C. Beard]

In article <3m420j$1...@gap.cco.caltech.edu> Seth LaForge,
set...@gluttony.ugcs.caltech.edu writes:

>Am I missing something here? Is there some way to define a method of
>some class (using method in the traditional sense of the word) and be
>garunteed that there won't be a name collision? I suppose one could
>always use explicit names for methods (window-draw and
>card-deck-draw), but that's a lot of work...

Name conflicts are handled by using modules. This allows you to design
your classes with natural names, and provides a powerful way to
rename variables where they are used.

For the example you give, it makes sense that you would put code for
windows and decks of cards into separate modules. If you define a
module that uses both windows and cards, you can rename all imported
variables with a prefix, or selected variables that conflict.

I agree with you that having multiple name spaces is sometimes
convenient, but modules do provide a powerful solution to naming
conflicts. Certainly better than using C macros to rename conflicting
functions in header files.

// author: Patrick C. Beard
// organization: Computing Research Group
// e-mail: be...@cs.ucdavis.edu