Mailing-List: contact users-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.apache.org
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: interface/implementation patten
From: OC <ocs@ocs.cz>
In-Reply-To: <56FC1F8C.3090007@gmx.org>
Date: Wed, 30 Mar 2016 21:07:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <64F3A2B8-4161-473B-B191-2A4A7FA7F54B@ocs.cz>
References: <1459093137891-5732080.post@n5.nabble.com>
 <B0F21CEC-7620-4DD1-9A0E-41CEB1448B63@ocs.cz>
 <1459150970302-5732082.post@n5.nabble.com>
 <B5D2686A-4783-47F5-A295-5D19CE438B0B@ocs.cz>
 <1459173202252-5732085.post@n5.nabble.com>
 <D73EE835-D38D-446D-8D0C-0E7C24A98E9D@ocs.cz>
 <0CD793C2-B644-43CF-8E6B-22F19EB7F696@ocs.cz> <56FBECE0.1070308@gmx.org>
 <B17D3C82-A3DA-4307-ABA4-3845EED6D327@ocs.cz> <56FC1F8C.3090007@gmx.org>
To: users@groovy.apache.org

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 =84methods=93 :)

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 =93this=93 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 =93impossible=94 and =
=93impractically difficult=94 :(

> 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 =93methods=93, it's much more -- =
including the =93Cannot cast object=94 exception howler of the other =
thread); but well, they did not, triple alas.

Anyway, far as static =84methods=93, 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