groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OC <...@ocs.cz>
Subject Re: interface/implementation patten
Date Wed, 30 Mar 2016 19:07:23 GMT
Jochen,

On 30. 3. 2016, at 20:48, Jochen Theodorou <blackdrag@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


Mime
View raw message