On 30.03.2016 18:59, OC wrote:
Oh, by the way,
On 30. 3. 2016, at 17:12, Jochen Theodorou <blackd...@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
