[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-dev
Subject:    Re: [groovy-dev] ExpandoMetaClass and method closures
From:       "Danno Ferrin" <danno.ferrin () shemnon ! com>
Date:       2008-05-30 14:06:39
Message-ID: 29cac3430805300706n3b029e0dked7ab269a9776d49 () mail ! gmail ! com
[Download RAW message or body]

On Fri, May 30, 2008 at 3:22 AM, Jochen Theodorou <blackdrag@gmx.org> wrote:

> Danno Ferrin schrieb:
>
>> The issue there is now we are making order of decleration.. which by
>> definition is indetermanate (but repeatable inside a single JVM).  In my
>> case I had to put the Object method in the middle (XP pentium 4/HT), leading
>> with it didn't work.
>>
>
> this sounds very much like a method ordering bug. Normally the order of the
> method should not have any influence at all.
>
>  Looks like more ways to break the mop when we look at 2.0...
>>
>
> what do you mean?
>

More things to place on the list of "make it work" that doesn't work now but
probably should.  This code block is no reason to stop any release, it's
just another 'should work but doesn't' case that is rarely encountered.
(except when I try and do exotic tricks, the kind statically typed languages
warned me about).

I've done some digging, and as best I can tell the MethodClosure when asked
for parameter types nominates for parameters one of the methods declared in
the class it comes from, but just one.  So in my first case the types are
not compatible, and EMC only accepts one of the versions (that changes on a
per-JVM basis), but if an Object type is thrown in somewhere (and it's
needed location changes based on the number and names of other methods) then
types become compatible (iff the Object variant is nominated as the
signature) since multi-method dispatch still works.

So I see two ways to address it, (a) allow method closures to have there
parameters settable from the outside (throwing an exception on a bogus set)
or (b) when adding a meta method to  ExpandoMetaClass, have it check to see
if it is getting a MethodClosure, and sniffing the type of the class and
adding all appropriate signatures if appropriate.  There are corner cases
with adding too much, but unless we are talking about a different number of
parameters the multi-method dispatch will undo the deliberate
non-registration of an overloaded name.


------------------------------------------------------
I'm Danno Ferrin, and I approved this message.

[Attachment #3 (text/html)]

<br><br><div class="gmail_quote">On Fri, May 30, 2008 at 3:22 AM, Jochen Theodorou \
&lt;<a href="mailto:blackdrag@gmx.org">blackdrag@gmx.org</a>&gt; \
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Danno Ferrin schrieb:<div \
class="Ih2E3d"><br> <blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The issue there \
is now we are making order of decleration.. which by definition is indetermanate (but \
repeatable inside a single JVM). &nbsp;In my case I had to put the Object method in \
the middle (XP pentium 4/HT), leading with it didn&#39;t work.<br>

</blockquote>
<br></div>
this sounds very much like a method ordering bug. Normally the order of the method \
should not have any influence at all.<div class="Ih2E3d"><br> <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Looks like more ways to break the mop \
when we look at 2.0...<br> </blockquote>
<br></div>
what do you mean?<br>
</blockquote><div><br>More things to place on the list of &quot;make it work&quot; \
that doesn&#39;t work now but probably should.&nbsp; This code block is no reason to \
stop any release, it&#39;s just another &#39;should work but doesn&#39;t&#39; case \
that is rarely encountered. (except when I try and do exotic tricks, the kind \
statically typed languages warned me about).<br> <br>I&#39;ve done some digging, and \
as best I can tell the MethodClosure when asked for parameter types nominates for \
parameters one of the methods declared in the class it comes from, but just \
one.&nbsp; So in my first case the types are not compatible, and EMC only accepts one \
of the versions (that changes on a per-JVM basis), but if an Object type is thrown in \
somewhere (and it&#39;s needed location changes based on the number and names of \
other methods) then types become compatible (iff the Object variant is nominated as \
the signature) since multi-method dispatch still works.<br> </div></div><br>So I see \
two ways to address it, (a) allow method closures to have there parameters settable \
from the outside (throwing an exception on a bogus set) or (b) when adding a meta \
method to&nbsp; ExpandoMetaClass, have it check to see if it is getting a \
MethodClosure, and sniffing the type of the class and adding all appropriate \
signatures if appropriate.&nbsp; There are corner cases with adding too much, but \
unless we are talking about a different number of parameters the multi-method \
dispatch will undo the deliberate non-registration of an overloaded name.<br \
clear="all"> <br><br>------------------------------------------------------<br>I&#39;m \
Danno Ferrin, and I approved this message.



[prev in list] [next in list] [prev in thread] [next in thread]