I see. The problem is that you can't tell in advance which methods might be
called with proxy-super, so you'd have to generate proxy-super methods for
all non-public superclass methods. It's an interesting idea. I suspect it's
a fairly tricky change since you'd have to change the method resolution for
the dot form to cope with it, since currently it searches methods in the
superclass - the proxy class is not available at compile time (actually,
I'm not 100% sure on this, I'd need to check the code).
Honestly, I think given that level of hackery and given the requirement to
modify the compiler anyway, I'd go straight for a more sane extend-class
form.
On 27 December 2013 17:49, Cedric Greevey <cgree...@gmail.com> wrote:
> On Thu, Dec 26, 2013 at 6:57 PM, Colin Fleming <
> colin.mailingl...@gmail.com> wrote:
>
>> The problem is that your approach requires creating the proxy class with
>> the method bodies actually compiled into the body of the proxy class
>> method, they can't be in fns in a proxy map as they are now. This is ok in
>> the case where a method body is just the proxy-super call, but most aren't
>> - they call proxy-super as part of a much larger method. Changing that is a
>> fundamental change to the way proxies work, and IMO would be better served
>> by creating a new form (extend-class or something similar) which would
>> behave in a more similar way to reify but would allow extension.
>>
>
> If you read my previous post carefully, it says that *the proxy-super
> call* (if any) would need to go into the method body. Think something like
> this.
>
> Java:
>
> public class Whatever extends SomeClass {
> public int someMethod (int x, String y) {
> x = fred(x,42);
> int foo = super.someMethod(x, y); // someMethod protected in
> SomeClass
> return mumble(foo, thingy.frotz(x));
> }
> }
>
> proxy (now) (byte code equivalent of):
>
> public class Whatever extends SomeClass {
> public Map<String,IFn> proxyMap = <some long&messy initializer>;
>
> public int someMethod (int x, String y) {
> return proxyMap.get("someMethod").invoke(this, x,y);
> }
>
> // And a similar thingy for each additional public-or-protected method
> in SomeClass
> }
>
> public class WhateverSomeMethodVersion1 implements IFn {
> public Object invoke (Whatever th1s, Object x, Object y) {
> x = th1s.fred((int)(Integer)x,42);
> int foo = Class.forName("SomeClass")
> .getMethod("someMethod", Integer.TYPE, String.class)
> .invoke(th1s, (int)(Integer)x, (String)y); // Eww, reflection,
> slow slow slow
> return th1s.mumble(foo, thingy.frotz((int)(Integer)x));
> }
> }
>
> proxy (proposed) (byte code equivalent of):
>
> public class Whatever extends SomeClass {
> public Map<String,IFn> proxyMap = <some long&messy initializer>;
>
> public int proxySuperSomeMethod (Object x, Object y) {
> super.someMethod((int)(Integer)x, (String)y); // Needs .! or
> whatever to emit
> }
>
> // And a similar thingy for each additional protected method in
> SomeClass
>
> public int someMethod (int x, String y) {
> return proxyMap.get("someMethod").invoke(this, x,y);
> }
>
> // And a similar thingy for each additional public-or-protected method
> in SomeClass
> }
>
> public class WhateverSomeMethodVersion1 implements IFn {
> public Object invoke (Whatever th1s, Object x, Object y) {
> x = th1s.fred((int)(Integer)x,42);
> int foo = th1s.proxySuperSomeMethod(x, y);
> return th1s.mumble(foo, thingy.frotz((int)(Integer)x));
> }
> }
>
>
>> I've considered writing such a thing myself due to the limitations and
>> idiosyncrasies of proxy/genclass but I've not investigated whether it's
>> even possible without hacking the compiler - I suspect it's not.
>>
>
> Not without implementing ".!" (or whatever name you prefer), or adding
> another bytecode emitter specialized to produce proxySuperSomeMethods. I
> guess every proxied class will need a proxy-hook subclass with
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
