[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-kawa] [bug #39048] Bad method call resolution?
From: |
Matthieu Vachon |
Subject: |
[Bug-kawa] [bug #39048] Bad method call resolution? |
Date: |
Fri, 07 Jun 2013 14:33:33 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36 |
Follow-up Comment #2, bug #39048 (project kawa):
Thanks for the link to the documentation, I guess I missed it when I first
search for it. Didn't know this feature since we do not use it. But we use the
other form which consist of using dashes to separate words of a method call.
First, about point 2), I totally agree with you that this case is
a bit special. We use it in our code base (i.e. a field is a
procedure) but we don't have cases where the field collapse
with a method but I guess it could happen. For example,
we could have a field `validator` and one of the method in the class could be
named `getValidator`.
This is how I see a possible solution to the problem. We have some sort of
ambiguity and must choose the closest possible match. I think a ranking
mechanism (maybe with other criteria) could solve almost every case. For other
cases, users should be responsible to avoid collision.
>From my point of view, if we have more than one possible method that could be
called, we should first look at the arity of the method. If arities are
different, pick the one with the closest arity (or even issue a warning if
arity does not match any).
If there is still more than one method, I see two possibilities.
1. We use name to discriminate. A kind of distance between the two names
could be used, and we pick the one with the closest match. So
`image-descriptor`, since it exactly match outer-scope function, would call
this one. On the other side, using `get-image-descriptor` would call class
method.
2. We use the types to discriminate. But it could be more difficult to choose
the right method in this case. Not sure it would be that good or even possible
due to dynamic nature of language.
I have a preference for only using 1. But we could combine the two
possibilities and order of checks could be 1 then 2 or 2 then 1. But I have a
preference for order 1 then 2, which should be more accurate.
Just my two cent on the issue. Whatever way you decide to take, I will follow
it. In fact, I already workaround the problem by creating a proxy method
outside of class scope that is calling the right procedure. The proxy just
have a name that do no collide with `getImageDescriptor`.
Regards,
Matt
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?39048>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/