You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by OC <oc...@ocs.cz> on 2016/03/29 18:15:40 UTC
Proxying how to?!? (was: changing dynamically the name of classes in a source code)
Incidentally...
On 28. 3. 2016, at 18:10, OC <oc...@ocs.cz> wrote:
> completely absurd and very anti-object-oriented) “Cannot cast object” exception.
... this reminded me of a problem I so far haven't been able to find a proper solution for: how the heck do you proxy in Groovy?
In ObjC, I can write
===
@interface AnyClassOfMine:Beanlike
@property NSString *name;
@end
@implementation AnyClassOfMine @end
@interface DumbProxy:Beanlike
@property id server;
@end
@implementation DumbProxy
-forwardingTargetForSelector:(SEL)sel { return self.server; }
@end
id objects=@[[AnyClassOfMine new:@"name":@"Direct"],[DumbProxy new:@"server":[AnyClassOfMine new:@"name":@"Proxied"]]];
for (AnyClassOfMine *o in objects) NSLog(@"got %@",o.name);
===
and it works precisely as assumed, writing out
===
2016-03-29 17:57:37.501 a.out[5387:707] got Direct
2016-03-29 17:57:37.503 a.out[5387:707] got Proxied
===
(Note if interested: the Beanlike superclass is irrelevant, it just simulates the new Foo(bar:bax) functionality of Groovy, which ObjC does not have, by implementing the new:(property-name):(value) method.)
Groovy -- unlike pure Java -- is smart enough to allow me to _implement_ such a proxy, but for sweet world, I cannot find a way to _use_ it?
===
class AnyClassOfMine {
def name
}
class DumbProxy {
def server
def propertyMissing(String name) {
server."$name"
}
}
def objects=[new AnyClassOfMine(name:"Direct"),new DumbProxy(server:new AnyClassOfMine(name:"Proxied"))]
for (AnyClassOfMine o in objects) println "got $o.name"
===
Alas, instead of working as expected, this fails with the aforementioned nonsensical exception:
===
got Direct
Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'DumbProxy@73f43791' with class 'DumbProxy' to class 'AnyClassOfMine'
...
===
How do you write and use a proxy in Groovy, so that it works properly?
(Note: “for (o in objects) ...” would work is this case, but would bring other problems, e.g., if there was a method “foo(AnyClassOfMine obj)“ called as “for (o in objects) foo(o)”, it would cause “No signature of method is applicable for argument types: (DumbProxy)”.)
Thanks a lot,
OC
Re: Proxying how to?!?
Posted by OC <oc...@ocs.cz>.
Jochen,
thank you very much for quick and, as always, very knowledgeable response!
On 30. 3. 2016, at 17:12, Jochen Theodorou <bl...@gmx.org> wrote:
> There are multiple ways to "solve" the problem, but I am afraid, they will all look like workarounds to you... The traditional Java way would be:
> interface InterfaceForAnyClassOfMine {
> def getName()
> }
...
Well of course, but the problem is with 3rd-party classes, which do not implement such an interface (and they might be even final, which prevents also all possible subclassing tricks and actually _forces_ proxying).
And generally, it is 3rd-party classes one needs to proxy most time; one's own classes (which I use here to quickly elucidate the gist of the problem) allow lots of other ways solve anything which might proxy be needed for.
> Then of course you would not use AnyClassOfMine as base, but InterfaceForAnyClassOfMine. You can make this a little bit more easy with @Delegate:
> class DumbProxy {
> @Delegate InterfaceForAnyClassOfMine server
> }
I do not like this approach, for it does not cover dynamics of the server -- far as I understand it properly, that is.
If the proxy forwards instead, i.e.,
===
class DumbProxy { def server; def methodMissing(name,args) { server."$name"(*args) } }
===
it covers even e.g., any functionality which has been added to server through its metaclass at runtime.
On the other hand, I grant @Delegate one definite advantage (its methods would work when called from Java, which methodMissing can't ever do, I am afraid), and one potential -- it might be considerably faster[*].
> Using runtime traits I would come up with this version:
> class AnyClassOfMine { def name }
> trait DumbProxy {}
> def objects=[new AnyClassOfMine(name:"Proxied") as DumbProxy]
> for (DumbProxy o in objects) println "got $o.name"
This seems very interesting! I simply _must_ clean up my quagmire of ASTTs so that they work with traits! (While I completely appreciate the strong reasons which led you to sort-of deprecate ASTTs with traits, I must admit for me it was _very_ sad decision, which still, even today, prevents me to use traits and forces me to stick with 3.8 :( )
> I think the basic problem is that you have no multiple inheritance in Java and only an inconsitent fraction of it in Groovy.
Sort of. Myself, I would rather say the problem is basically in the Java terrible howler of making static class/interface relationships overimportant.
ObjC does not have MI either, but it can be easily _simulated_ in there using message forwarding. In Groovy (even in plain Java, with some boilerplate code essentially doing by hand what your @Delegate ASTT does), it would work just as well, only if it were possible to typecast a DumbProxy instance to AnyClassOfMine. There is no harm in it, for any method callable of AnyClassOfMine is also callable of DumbProxy; alas, Java atrifically (and dumbly) closes that door by the very “Cannot cast object” exception.
> So on the JVM I cannot make a class that implements a class AnyClassOfMine and DumbProxy at the same time.
That is actually not needed at all. All we need is that the JVM calls AnyClassOfMine methods on DumbProxy object. Which is problematic in pure Java (I understand one needs reflexion for that, can be done, but is beyond ugly), but no problem at all in Groovy.
Groovy does allow that, and it works excellectly, if we stick with “def”. The problem occurs when there is an existing API which not only _uses_ an instance of AnyClassOfMine, but also _declares it_ as one. E.g.,
def gimmeObject { return flag?objectOfClassX:proxyToClassX } //[1]
works as-is without any glitch. Contrariwise
ClassX gimmeObject { return flag?objectOfClassX:proxyToClassX }
does not, only due to the blasted “Cannot cast object” exception; if it was not for that thing, it would work just as well as [1] above.
> I can do such things with interfaces though. This again forces people to split their classes in interfaces and implementations, both being first class citizens. Objective C is much more flexible here.
I don't really think so. First, ObjC is actually more rigid in many places (e.g., it _forces_ you to split _any_ class to interface and implementation, willy-nilly :)), but the one (and in this particular context I belive _only_ important) difference is that it freely lets you cast anything to anything. The compiler, of course, behaves accordingly, trusting you you had a good reason to do that typecast.
Of course, if you typecast, say, a Map to a String, the program would crash as soon as the real Map gets first String's message it does not implement; but there's no potential problem in that -- nobody sane would do such a typecast (and whomever would, serves him right).
On the other hand, it allows proxying. And more.
> But it means I cannot apply the same concept to the JVM world... not if I want to stay with the Java class model.
That all said, I am afraid this still applies -- far as I understand, you not only can't make “a class that implements a class AnyClassOfMine and DumbProxy at the same time” (which is not needed), but you also cannot make a class which
(a) would implement DumbProxy; any method called on its instance would be interpreted normally
(b) at the same moment, would _look to_ the compiler _like_ AnyClassOfMine in the sense it would call AnyClassOfMine's methods on its instances (and use AnyClassOfMine to resolve calls which depend on argument type etc.)
Note that (b) would not _change_ the class anyhow; it would still stay a true-blue DumbProxy. The only difference is that compiler would use it _as it were_ an AnyClassOfMine (which it is not).
> ... But once you have two super classes you are lost... especially without the magic -forwardingTargetForSelector:(SEL)sel { return self.server; }
I believe _this_ one magic you could implement in Groovy dispatcher, if you wanted, and pretty easily at that. It is nothing but a quick-and-fast shortcut to “methodMissing(name,args) { target."$name"(*args) }”, which only forwards and does not pre-/post-process the method, nothing else. Its purpose is to make it easier for programmer and faster runtime, but the functionality is precisely the same[**].
Thanks and all the best,
OC
[*] On the other hand, the speed difference should not be that big if the forwarding is done right, that is, at first forward the proxy itself installs the stub through its own metaclass. Nevertheless, that's an optimization which works nicely (most time), but is not relevant to the current debate.
[**] Actually in Groovy you would probably have to solve properties separately; ObjC has properties too, but defines them solely through their accessors, which, I believe, is easier -- at least, you don't need separate “methodMissing” and “propertyMissing” (twice) etc., for “methodMissing” catches property accessors just as well as all other methods. But this, too, is completely irrelevant to the current discussion :)
Re: static propertyMissing in an interface
Posted by OC <oc...@ocs.cz>.
Jochen,
On 3. 4. 2016, at 22:29, Jochen Theodorou <bl...@gmx.org> wrote:
> On 03.04.2016 17:33, OC wrote:
> [...]
>> ===
>> 6 /tmp> <q.groovy
>> class q {
>> static main(av) {
>> ExpandoMetaClass.enableGlobally()
>> Root.metaClass.static.propertyMissing={ name ->
>> String getter="get${name.capitalize()}"
>> def body={-> "<$name in $delegate>" }
>> delegate.metaClass.static."$getter"=body
>> body.call() // same problem with body(); delegate."$getter"() would work though
>> }
>> println "- ${Root.weird}"
>> }
>> }
>> interface Root {}
>> 7 /tmp> groovy q.groovy
>> Caught: groovy.lang.MissingMethodException: No signature of method: java.io.StringWriter.capitalize() is applicable for argument types: () values: []
>> groovy.lang.MissingMethodException: No signature of method: java.io.StringWriter.capitalize() is applicable for argument types: () values: []
>> at q$_main_closure1.doCall(q.groovy:5)
>> at q.main(q.groovy:10)
>> 8 /tmp>
>
> so I misunderstood... it was not, that somehow body was not recognized as closure or such, it is that the execution of code inside fails. capitalize() is a method on CharSequence, StringWriter is no CharSequence, so the call fails. Did you add such a method yourself? if not, you need to convert to String first.
Convert what?
I call the capitalize method only once, on the name argument of the propertyMissing closure. That is/should be always a String, should it not? Or is there a valid case where this argument would be something else?
Besides the problem disappears if the "body()" or "body.call()" call gets replaced by "delegate."$getter"()", which is sort of weird, for delegate."$getter" actually contains the very body closure :-O
It looks like the way the body closure captures the name variable is... weird: it seems when body.call() is performed, the propertyMissing closure gets called again, this time with a StringWriter for "name", in a way which is completely obscure to me:
===
14 /tmp> <q.groovy
class q {
static main(av) {
ExpandoMetaClass.enableGlobally()
Root.metaClass.static.propertyMissing={ String name ->
def body={-> "<$name in $delegate>" }
body.call()
}
println "- ${Root.weird}"
}
}
interface Root {}
15 /tmp> groovy q.groovy
Caught: groovy.lang.MissingMethodException: No signature of method: q$_main_closure1.doCall() is applicable for argument types: (java.io.StringWriter) values: [- <weird in ]
...
16 /tmp>
===
Thank you very much and all the best,
OC
Re: static propertyMissing in an interface
Posted by Jochen Theodorou <bl...@gmx.org>.
On 03.04.2016 17:33, OC wrote:
[...]
> ===
> 6 /tmp> <q.groovy
> class q {
> static main(av) {
> ExpandoMetaClass.enableGlobally()
> Root.metaClass.static.propertyMissing={ name ->
> String getter="get${name.capitalize()}"
> def body={-> "<$name in $delegate>" }
> delegate.metaClass.static."$getter"=body
> body.call() // same problem with body(); delegate."$getter"() would work though
> }
> println "- ${Root.weird}"
> }
> }
> interface Root {}
> 7 /tmp> groovy q.groovy
> Caught: groovy.lang.MissingMethodException: No signature of method: java.io.StringWriter.capitalize() is applicable for argument types: () values: []
> groovy.lang.MissingMethodException: No signature of method: java.io.StringWriter.capitalize() is applicable for argument types: () values: []
> at q$_main_closure1.doCall(q.groovy:5)
> at q.main(q.groovy:10)
> 8 /tmp>
so I misunderstood... it was not, that somehow body was not recognized
as closure or such, it is that the execution of code inside fails.
capitalize() is a method on CharSequence, StringWriter is no
CharSequence, so the call fails. Did you add such a method yourself? if
not, you need to convert to String first.
bye Jochen
Re: static propertyMissing in an interface
Posted by OC <oc...@ocs.cz>.
Jochen,
On 3. 4. 2016, at 7:23, Jochen Theodorou <bl...@gmx.org> wrote:
> On 01.04.2016 03:48, OC wrote:
>> playing with possibilities of the i/i pattern, I have found one can install a static property to an interface, and then use the property all right -- see a proof-of-concept below.
>>
>> Since it might be used e.g. to create instances or to get a factory through public API based on interfaces (which would otherwise not be possible without exposing the implementation class), this is truly interesting.
>>
>> The question is: can I rely on this rather arcane behaviour, that it will not be broken in future Groovy versions?
>
> if you want to be really sure it will continue working it is best if you contribute a test case ;) But I see no plans to change that, especially with java8 being able to define static methods and thus static properties.
Thanks a lot!
> [...]
>> def body={-> "<$name in $delegate>" }
>> delegate.metaClass.static."$getter"=body
>> delegate."$getter"() // I wonder why just "body()" does not work?!?
>
> no idea why not... but you can always try body.call() instead.
Same as with body():
===
6 /tmp> <q.groovy
class q {
static main(av) {
ExpandoMetaClass.enableGlobally()
Root.metaClass.static.propertyMissing={ name ->
String getter="get${name.capitalize()}"
def body={-> "<$name in $delegate>" }
delegate.metaClass.static."$getter"=body
body.call() // same problem with body(); delegate."$getter"() would work though
}
println "- ${Root.weird}"
}
}
interface Root {}
7 /tmp> groovy q.groovy
Caught: groovy.lang.MissingMethodException: No signature of method: java.io.StringWriter.capitalize() is applicable for argument types: () values: []
groovy.lang.MissingMethodException: No signature of method: java.io.StringWriter.capitalize() is applicable for argument types: () values: []
at q$_main_closure1.doCall(q.groovy:5)
at q.main(q.groovy:10)
8 /tmp>
===
Thanks again and all the best,
OC
Re: static propertyMissing in an interface
Posted by Jochen Theodorou <bl...@gmx.org>.
On 01.04.2016 03:48, OC wrote:
> Hello there,
>
> playing with possibilities of the i/i pattern, I have found one can install a static property to an interface, and then use the property all right -- see a proof-of-concept below.
>
> Since it might be used e.g. to create instances or to get a factory through public API based on interfaces (which would otherwise not be possible without exposing the implementation class), this is truly interesting.
>
> The question is: can I rely on this rather arcane behaviour, that it will not be broken in future Groovy versions?
if you want to be really sure it will continue working it is best if you
contribute a test case ;) But I see no plans to change that, especially
with java8 being able to define static methods and thus static properties.
[...]
> def body={-> "<$name in $delegate>" }
> delegate.metaClass.static."$getter"=body
> delegate."$getter"() // I wonder why just "body()" does not work?!?
no idea why not... but you can always try body.call() instead.
bye Jochen
static propertyMissing in an interface (was: interface/implementation patten)
Posted by OC <oc...@ocs.cz>.
Hello there,
playing with possibilities of the i/i pattern, I have found one can install a static property to an interface, and then use the property all right -- see a proof-of-concept below.
Since it might be used e.g. to create instances or to get a factory through public API based on interfaces (which would otherwise not be possible without exposing the implementation class), this is truly interesting.
The question is: can I rely on this rather arcane behaviour, that it will not be broken in future Groovy versions?
Thanks,
OC
===
78 /tmp> <q.groovy
class q {
static main(av) {
ExpandoMetaClass.enableGlobally()
Root.metaClass.static.propertyMissing={ name ->
String getter="get${name.capitalize()}"
println "... PMISS($name) in $delegate, installing $getter()"
def body={-> "<$name in $delegate>" }
delegate.metaClass.static."$getter"=body
delegate."$getter"() // I wonder why just "body()" does not work?!?
}
println "- ${Foo.staticPropertyOfInterfaceWow}"
println "- ${Bar.itReallyWorks}"
println "second time, they go directly without PMISS"
println "- ${Foo.staticPropertyOfInterfaceWow}"
println "- ${Bar.itReallyWorks}"
}
}
interface Root {}
interface Foo extends Root {
}
interface Bar extends Foo {
}
79 /tmp> groovy q
... PMISS(staticPropertyOfInterfaceWow) in interface Foo, installing getStaticPropertyOfInterfaceWow()
- <staticPropertyOfInterfaceWow in interface Foo>
... PMISS(itReallyWorks) in interface Bar, installing getItReallyWorks()
- <itReallyWorks in interface Bar>
second time, they go directly without PMISS
- <staticPropertyOfInterfaceWow in interface Foo>
- <itReallyWorks in interface Bar>
80 /tmp>
===
Re: interface/implementation patten
Posted by OC <oc...@ocs.cz>.
Jochen,
On 30. 3. 2016, at 20:48, Jochen Theodorou <bl...@gmx.org> wrote:
> I am unhappy about the semantics of static methods in general in Java and that we copied most of it in Groovy...
You are telling me :) Hardly you can have missed my occassional bitter rants re static „methods“ :)
I sort of recall we debated ages ago whether there might be a way to turn them to real full-fledged class methods, properly inheritable with a real “this“ representing the receiver, not the implementor; but I am afraid the result of that conversation was that something like that would be somewhere at the edge betwixt “impossible” and “impractically difficult” :(
> extending that to interface is for me no good decision... but well...
I would be infinitely happier if those jokers in Sun have designed the thing properly (it's not just static “methods“, it's much more -- including the “Cannot cast object” exception howler of the other thread); but well, they did not, triple alas.
Anyway, far as static „methods“, with all their shortcomings, can be part of the class API, I am afraid the interface needs to be able to contain the things. After all, that's the purpose of the interface: to define the public API of the class; no less, no more. If the public API can contain those uglies, the interface should, too.
Or am I overlooking something of importance here?
> I guess it is up to you. I know of nothing in that area to make this less painful
OK, thanks; I guess I'll try to rig some kind of private preprocessor reading sources which would contain ObjC-like class directives, and generating the appropriate .groovy files with all the interfaces, implementations, factories etc. After all, ages ago the C preprocessor used to be implemented this very way, and it worked well.
It would complicate somewhat the incremental build on one side, and error reporting (more precisely, matching the reports to sources) on the other; but the problems should not be insurmountable, I guess -- I need to postprocess error reports anyway, since I use Xcode instead of Eclipse, and thus I have to squeeze the reports so that Xcode understands them. And the big advantage (against the ASTT approach) would be no problem with traits :)
Thanks again a very big lot and all the best,
OC
Re: interface/implementation patten
Posted by Jochen Theodorou <bl...@gmx.org>.
On 30.03.2016 18:59, OC wrote:
> Oh, by the way,
>
> On 30. 3. 2016, at 17:12, Jochen Theodorou <bl...@gmx.org> wrote:
>> This again forces people to split their classes in interfaces and implementations
>
> reminded me another question of mine. I actually want to embrace this pattern for a long time (after all, I am used to it from ObjC), but there are two problems:
>
> (a) interfaces cannot contain static methods
>
> I am afraid there would be no solution at all in Java-based world, or does Groovy bring some?
This require support through the JVM... and actually Java8 has that...
But I think we do not support that yet. I am unhappy about the semantics
of static methods in general in Java and that we copied most of it in
Groovy... extending that to interface is for me no good decision... but
well...
> (b) they force me to maintain two parallel hierarchies, like
>
> ===
> interface Foo {
> def foo();
> ...
> }
> class Foo_Implementation implements Foo {
> def foo() { ... }
> def myfoo() { ... }
> ...
> }
> interface Bar implements Foo {
> def bar();
> ...
> }
> class Bar_Implementation extends Foo_Implementation implements Bar {
> def bar() { ... }
> ...
> }
> ===
>
> with a high danger of a mistake leading to inconsistence of these two hierarchies. Not speaking of the factory pattern to replace those pesky static methods, which would, alas, add a third hierarchy for factories; if I wanted to use interface/implementations for factories too, I get _four_ parallel hierarchies, which need to keep consistent! Quadruple ick.
>
> Is there some trick in Groovy which makes this task groovier (or at the very least reasonably manageable), or am I up to my own source preprocessor and/or ASTTs (which again would clash with traits :/ )?
I guess it is up to you. I know of nothing in that area to make this
less painful
bye Jochen
RE: interface/implementation patten (was: Proxying how to?!?)
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
In Java 8+, interfaces can have static methods, and with default methods, you can simulate multiple inheritance. To be honest, I'm not sure how/if you can use this from Groovy -- if Groovy interface can define static or default methods. In the case of conflicts, Java forces you to override the shared method. From the override you can call one of the super class versions if you want.
public interface Foo {
static String getFoo() {
return "Foo";
}
default String foo() {
return getFoo();
}
default String shared() {
return foo();
}
}
public interface Bar {
default String bar() {
return "Bar";
}
default String shared() {
return bar();
}
}
public class FooBar implements Foo, Bar {
public static void main(String[] args) {
FooBar fooBar = new FooBar();
System.out.println(fooBar.foo());
System.out.println(fooBar.bar());
System.out.println(fooBar.shared());
}
@Override
public String shared() {
return Foo.super.shared();
}
}
Jason
-----Original Message-----
From: OC [mailto:ocs@ocs.cz]
Sent: Wednesday, March 30, 2016 12:59 PM
To: users@groovy.apache.org
Subject: interface/implementation patten (was: Proxying how to?!?)
Oh, by the way,
On 30. 3. 2016, at 17:12, Jochen Theodorou <bl...@gmx.org> wrote:
> This again forces people to split their classes in interfaces and implementations
reminded me another question of mine. I actually want to embrace this pattern for a long time (after all, I am used to it from ObjC), but there are two problems:
(a) interfaces cannot contain static methods
I am afraid there would be no solution at all in Java-based world, or does Groovy bring some?
(b) they force me to maintain two parallel hierarchies, like
===
interface Foo {
def foo();
...
}
class Foo_Implementation implements Foo {
def foo() { ... }
def myfoo() { ... }
...
}
interface Bar implements Foo {
def bar();
...
}
class Bar_Implementation extends Foo_Implementation implements Bar {
def bar() { ... }
...
}
===
with a high danger of a mistake leading to inconsistence of these two hierarchies. Not speaking of the factory pattern to replace those pesky static methods, which would, alas, add a third hierarchy for factories; if I wanted to use interface/implementations for factories too, I get _four_ parallel hierarchies, which need to keep consistent! Quadruple ick.
Is there some trick in Groovy which makes this task groovier (or at the very least reasonably manageable), or am I up to my own source preprocessor and/or ASTTs (which again would clash with traits :/ )?
Thanks a lot,
OC
----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
interface/implementation patten (was: Proxying how to?!?)
Posted by OC <oc...@ocs.cz>.
Oh, by the way,
On 30. 3. 2016, at 17:12, Jochen Theodorou <bl...@gmx.org> wrote:
> This again forces people to split their classes in interfaces and implementations
reminded me another question of mine. I actually want to embrace this pattern for a long time (after all, I am used to it from ObjC), but there are two problems:
(a) interfaces cannot contain static methods
I am afraid there would be no solution at all in Java-based world, or does Groovy bring some?
(b) they force me to maintain two parallel hierarchies, like
===
interface Foo {
def foo();
...
}
class Foo_Implementation implements Foo {
def foo() { ... }
def myfoo() { ... }
...
}
interface Bar implements Foo {
def bar();
...
}
class Bar_Implementation extends Foo_Implementation implements Bar {
def bar() { ... }
...
}
===
with a high danger of a mistake leading to inconsistence of these two hierarchies. Not speaking of the factory pattern to replace those pesky static methods, which would, alas, add a third hierarchy for factories; if I wanted to use interface/implementations for factories too, I get _four_ parallel hierarchies, which need to keep consistent! Quadruple ick.
Is there some trick in Groovy which makes this task groovier (or at the very least reasonably manageable), or am I up to my own source preprocessor and/or ASTTs (which again would clash with traits :/ )?
Thanks a lot,
OC
Re: Proxying how to?!?
Posted by Jochen Theodorou <bl...@gmx.org>.
On 29.03.2016 18:15, OC wrote:
[...]
> class AnyClassOfMine {
> def name
> }
>
> class DumbProxy {
> def server
> def propertyMissing(String name) {
> server."$name"
> }
> }
>
> def objects=[new AnyClassOfMine(name:"Direct"),new DumbProxy(server:new AnyClassOfMine(name:"Proxied"))]
> for (AnyClassOfMine o in objects) println "got $o.name"
> ===
>
> Alas, instead of working as expected, this fails with the aforementioned nonsensical exception:
>
> ===
> got Direct
> Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'DumbProxy@73f43791' with class 'DumbProxy' to class 'AnyClassOfMine'
> ...
> ===
There are multiple ways to "solve" the problem, but I am afraid, they
will all look like workarounds to you... The traditional Java way would be:
interface InterfaceForAnyClassOfMine {
def getName()
}
class AnyClassOfMine implements InterfaceForAnyClassOfMine {
def name
}
class DumbProxy implements InterfaceForAnyClassOfMine {
InterfaceForAnyClassOfMine server
def getName() {
server.name
}
}
Then of course you would not use AnyClassOfMine as base, but
InterfaceForAnyClassOfMine. You can make this a little bit more easy
with @Delegate:
class DumbProxy {
@Delegate InterfaceForAnyClassOfMine server
}
@Delegate will add the implements clause for you, as well as any compile
time defined method of InterfaceForAnyClassOfMine... basically you safe
a few lines. But basically DumbProxy does not have anything to do with
AnyClassOfMine, so no runtime solution will really work here, if you
still want to base on static types at some place.
Using runtime traits I would come up with this version:
class AnyClassOfMine { def name }
trait DumbProxy {}
def objects=[new AnyClassOfMine(name:"Proxied") as DumbProxy]
for (DumbProxy o in objects) println "got $o.name"
I think the basic problem is that you have no multiple inheritance in
Java and only an inconsitent fraction of it in Groovy. So on the JVM I
cannot make a class that implements a class AnyClassOfMine and DumbProxy
at the same time. I can do such things with interfaces though. This
again forces people to split their classes in interfaces and
implementations, both being first class citizens. Objective C is much
more flexible here. But it means I cannot apply the same concept to the
JVM world... not if I want to stay with the Java class model. Our traits
are kind of a hybrid, as they define multiple classes, one interface and
a specific implementation. Only because of that I can make a proxy here
and only of an interface. Dynamically generating a subclass is also
possible, and we actually do that as well in Groovy. But once you have
two super classes you are lost... especially without the magic
-forwardingTargetForSelector:(SEL)sel { return self.server; }
bye Jochen
Re: Proxying how to?!? (was: changing dynamically the name of classes in a source code)
Posted by OC <oc...@ocs.cz>.
Jason,
thanks for a quick response!
On 29. 3. 2016, at 19:09, "Winnebeck, Jason" <Ja...@windstream.com> wrote:
> You still have to follow the rules of Java bytecode
right, that's why I wrote it's a Java fault (inherited by Groovy), not a Groovy fault.
> that is your class DumbProxy is not related by class hierarchy or interface to AnyClassOfMine, so you can't cast to it.
That is precisely the problem: without casting to it, it can't be used.
> You have to use def/Object type and Groovy's duck typing, or you need to make DumbProxy extend AnyClassOfMine
Far as I understand the Groovy dispatch, this would force me not to go through a relatively clean missingXXX APIs; instead, I would probably have to exploit metaclass functionality directly, or something like that.
Well OK, that I can live with (unless it gets really slow, which it probably would not).
But what if the target class is final? Would never happen with AnyClassOfMine of course, but would happen with 3rd party classes whose instances I might need to proxy.
> or make an interface for them both to implement and use that.
Same problem there: whilst I can turn AnyClassOfMine to implement anything, I can't turn 3rd party classes to do that; and proxying 3rd party classes is essential (after all, with my own classes I can easily use other tricks than proxying to achieve the same result).
> Other options to consider include:
> http://docs.groovy-lang.org/latest/html/gapi/groovy/util/Proxy.html
Correct me please if I am overlooking anything, but it seems to me this is just slightly better implementation of DumbProxy. To redirect methods it uses invokeMethod instead of methodMissing (perhaps it is faster? Dunno. One advantage might be it would technically allow to forward even methods implemented in Proxy itself, but that is prevented by the implementation); but it _does_ share the very same typecasting problem we have just established with my DumbProxy.
Or does it not? If not, how comes?
> http://docs.groovy-lang.org/latest/html/gapi/groovy/util/ProxyGenerator.html
Well this seems really to create an instance of a dynamically made subclass (whoa! But I can see there's nothing else we can do with the bloody Java inherited behaviour), but I must be missing something. That instance does not work as a proxy, but seems to be half-proxy half-real instance of the target class.
Far as I has been able to test, it seems that
pg.instantiateDelegateWithBaseClass([:],[],delegate,class)
(a) creates a new instance of (a private subclas of) given “class” (OK)
(b) which instance gets all the methods (including property getters and setters) “class” contains, directly, without notifying the “delegate” anyhow (COMPLETELY WRONG)
(c) and only properties a methods the “class” does _not_ contain are directed to the delegate (OK)
The functionality needed for proxying differs from that:
(a) the proxied object (a server) exists before a proxy is created;
(b) the delegate (far as I understand what is its purpose?!?) should get _all_ the methods called “of the proxy”...
(c) ... so that it can (pre- or post-process them if need be and) forward them to the real proxied object.
Here's my testing code; perhaps you can point out what's wrong? The documentation is seriously lacking :)
===
class AnyClassOfMine {
def xxname // renamed from 'name' to be triple sure not to clash with proxy name or something
def foo(bar) { println "foo of $this called with $bar"; "${bar.toUpperCase()}, I am $xxname" }
}
class Delegate {
def server
def propertyMissing(String name) {
println "- delegate asked for a property '$name' for server $server"
if (name!='xxname') return 'nonexistent'
server."$name"
}
def propertyMissing(String name,value) {
println "- delegate asked to set a property '$name' to $value for server $server"
if (name!='xxname') return 'nonexistent'
server."$name"
}
def methodMissing(String name, args) {
println "- delegate asked for a method '$name'$args for server $server"
if (name!='foo') return 'nonexistent'
server."$name"(*args)
}
}
def proxied=new AnyClassOfMine(xxname:"Proxied"),delegate=new Delegate(server:proxied)
assert delegate.xxname=='Proxied'
def pg=groovy.util.ProxyGenerator.INSTANCE // is this the proper way to do it?
def proxy=pg.instantiateDelegateWithBaseClass([:],[],delegate,delegate.server.class)
assert proxy instanceof AnyClassOfMine
println "=== Delegate gets unknown method allright:"
println "-> ${proxy.unknown('hello')}"
println "=== Known method implemented by $proxy, instead of being sent through delegate to $proxied!"
println "-> ${proxy.foo('hello')}"
println "=== It should look like this:"
println "-> ${delegate.foo('hello')}"
println "=== Exactly same problem with properties: unknown one correctly forwarded..."
println "-> $proxy.unknownProperty"
println "=== Known property though processed directly by proxy, not forwarded through delegate to $proxied!"
println "-> $proxy.xxname (differs from $proxied.xxname; or read through delegate, $delegate.xxname)"
===
The results are
===
- delegate asked for a property 'xxname' for server AnyClassOfMine@263d0564
=== Delegate gets unknown method allright:
- delegate asked for a method 'unknown'[hello] for server AnyClassOfMine@263d0564
-> nonexistent
=== Known method implemented by Delegate1_groovyProxy@837a151, instead of being sent through delegate to AnyClassOfMine@263d0564!
foo of Delegate1_groovyProxy@837a151 called with hello
-> HELLO, I am null
=== It should look like this:
- delegate asked for a method 'foo'[hello] for server AnyClassOfMine@263d0564
foo of AnyClassOfMine@263d0564 called with hello
-> HELLO, I am Proxied
=== Exactly same problem with properties: unknown one correctly forwarded...
- delegate asked for a property 'unknownProperty' for server AnyClassOfMine@263d0564
-> nonexistent
=== Known property though processed directly by proxy, not forwarded through delegate to AnyClassOfMine@263d0564!
- delegate asked for a property 'xxname' for server AnyClassOfMine@263d0564
-> null (differs from Proxied; or read through delegate, Proxied)
===
Instead, proxy.foo should redirect to the delegate (and through it to server). Similarly, proxy.xxname should get/set the server xxname (through the delegate, again).
> http://docs.groovy-lang.org/latest/html/gapi/groovy/lang/Delegate.html
Again, correct me please if I am overlooking something, but this does not seem to have _anything_ in common with the thing we are solving, i.e., proxying.
Far as I understand, this exploits ASTTs to generate automatically things like
===
class Foo {
Bar server
def someBarMethod() { server.someBarMethod() }
void anotherBarMethod(foo,bar,baz) { server.anotherBarMethod(foo,bar,baz) }
....
// and so forth
}
===
That's rather ugly solution compared with dynamic redirection (though it might be much faster in the Java world, I did not benchmark it, but I can guess this probably will be the point of it; along with the problem that dynamically redirected methods would not work if called from pure Java, which might be enormously important for someone, luckily, completely irrelevant to me :)).
Thanks a lot,
OC
> -----Original Message-----
> From: OC [mailto:ocs@ocs.cz]
> Sent: Tuesday, March 29, 2016 12:16 PM
> To: users@groovy.apache.org
> Subject: Proxying how to?!? (was: changing dynamically the name of classes in a source code)
>
> Incidentally...
>
> On 28. 3. 2016, at 18:10, OC <oc...@ocs.cz> wrote:
>> completely absurd and very anti-object-oriented) "Cannot cast object" exception.
>
> ... this reminded me of a problem I so far haven't been able to find a proper solution for: how the heck do you proxy in Groovy?
>
> In ObjC, I can write
>
> ===
> @interface AnyClassOfMine:Beanlike
> @property NSString *name;
> @end
> @implementation AnyClassOfMine @end
>
> @interface DumbProxy:Beanlike
> @property id server;
> @end
> @implementation DumbProxy
> -forwardingTargetForSelector:(SEL)sel { return self.server; }
> @end
>
> id objects=@[[AnyClassOfMine new:@"name":@"Direct"],[DumbProxy new:@"server":[AnyClassOfMine new:@"name":@"Proxied"]]];
> for (AnyClassOfMine *o in objects) NSLog(@"got %@",o.name);
> ===
>
> and it works precisely as assumed, writing out
>
> ===
> 2016-03-29 17:57:37.501 a.out[5387:707] got Direct
> 2016-03-29 17:57:37.503 a.out[5387:707] got Proxied
> ===
>
> (Note if interested: the Beanlike superclass is irrelevant, it just simulates the new Foo(bar:bax) functionality of Groovy, which ObjC does not have, by implementing the new:(property-name):(value) method.)
>
> Groovy -- unlike pure Java -- is smart enough to allow me to _implement_ such a proxy, but for sweet world, I cannot find a way to _use_ it?
>
> ===
> class AnyClassOfMine {
> def name
> }
>
> class DumbProxy {
> def server
> def propertyMissing(String name) {
> server."$name"
> }
> }
>
> def objects=[new AnyClassOfMine(name:"Direct"),new DumbProxy(server:new AnyClassOfMine(name:"Proxied"))]
> for (AnyClassOfMine o in objects) println "got $o.name"
> ===
>
> Alas, instead of working as expected, this fails with the aforementioned nonsensical exception:
>
> ===
> got Direct
> Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'DumbProxy@73f43791' with class 'DumbProxy' to class 'AnyClassOfMine'
> ...
> ===
>
> How do you write and use a proxy in Groovy, so that it works properly?
>
> (Note: "for (o in objects) ..." would work is this case, but would bring other problems, e.g., if there was a method "foo(AnyClassOfMine obj)" called as "for (o in objects) foo(o)", it would cause "No signature of method is applicable for argument types: (DumbProxy)".)
>
> Thanks a lot,
> OC
>
> ----------------------------------------------------------------------
> This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
RE: Proxying how to?!? (was: changing dynamically the name of
classes in a source code)
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
You still have to follow the rules of Java bytecode, that is your class DumbProxy is not related by class hierarchy or interface to AnyClassOfMine, so you can't cast to it. You have to use def/Object type and Groovy's duck typing, or you need to make DumbProxy extend AnyClassOfMine or make an interface for them both to implement and use that.
Other options to consider include:
http://docs.groovy-lang.org/latest/html/gapi/groovy/util/Proxy.html
http://docs.groovy-lang.org/latest/html/gapi/groovy/util/ProxyGenerator.html
http://docs.groovy-lang.org/latest/html/gapi/groovy/lang/Delegate.html
Jason
-----Original Message-----
From: OC [mailto:ocs@ocs.cz]
Sent: Tuesday, March 29, 2016 12:16 PM
To: users@groovy.apache.org
Subject: Proxying how to?!? (was: changing dynamically the name of classes in a source code)
Incidentally...
On 28. 3. 2016, at 18:10, OC <oc...@ocs.cz> wrote:
> completely absurd and very anti-object-oriented) "Cannot cast object" exception.
... this reminded me of a problem I so far haven't been able to find a proper solution for: how the heck do you proxy in Groovy?
In ObjC, I can write
===
@interface AnyClassOfMine:Beanlike
@property NSString *name;
@end
@implementation AnyClassOfMine @end
@interface DumbProxy:Beanlike
@property id server;
@end
@implementation DumbProxy
-forwardingTargetForSelector:(SEL)sel { return self.server; }
@end
id objects=@[[AnyClassOfMine new:@"name":@"Direct"],[DumbProxy new:@"server":[AnyClassOfMine new:@"name":@"Proxied"]]];
for (AnyClassOfMine *o in objects) NSLog(@"got %@",o.name);
===
and it works precisely as assumed, writing out
===
2016-03-29 17:57:37.501 a.out[5387:707] got Direct
2016-03-29 17:57:37.503 a.out[5387:707] got Proxied
===
(Note if interested: the Beanlike superclass is irrelevant, it just simulates the new Foo(bar:bax) functionality of Groovy, which ObjC does not have, by implementing the new:(property-name):(value) method.)
Groovy -- unlike pure Java -- is smart enough to allow me to _implement_ such a proxy, but for sweet world, I cannot find a way to _use_ it?
===
class AnyClassOfMine {
def name
}
class DumbProxy {
def server
def propertyMissing(String name) {
server."$name"
}
}
def objects=[new AnyClassOfMine(name:"Direct"),new DumbProxy(server:new AnyClassOfMine(name:"Proxied"))]
for (AnyClassOfMine o in objects) println "got $o.name"
===
Alas, instead of working as expected, this fails with the aforementioned nonsensical exception:
===
got Direct
Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'DumbProxy@73f43791' with class 'DumbProxy' to class 'AnyClassOfMine'
...
===
How do you write and use a proxy in Groovy, so that it works properly?
(Note: "for (o in objects) ..." would work is this case, but would bring other problems, e.g., if there was a method "foo(AnyClassOfMine obj)" called as "for (o in objects) foo(o)", it would cause "No signature of method is applicable for argument types: (DumbProxy)".)
Thanks a lot,
OC
----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.