You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Jochen Theodorou <bl...@gmx.org> on 2016/03/30 17:12:32 UTC
Re: Proxying how to?!?
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?!?
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