Jochen, On 30. 3. 2016, at 20:48, Jochen Theodorou <[email protected]> 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
