Re: Interface inheritance vs Implementation inheritance.
Daniele Futtorovic wrote:
On 2008-02-19 23:10 +0100, Daniel Pitts allegedly wrote:
Peter Duniho wrote:
On Tue, 19 Feb 2008 13:27:19 -0800, Daniel Pitts
<newsgroup.spamfilter@virtualinfinity.net> wrote:
[...] I'm not saying that it is always and automatically bad. I
guess my main point was that there are situations where, due to
many language limitations, it is necessary to avoid a massive
amounts of boiler-plate delegation code. If you had a convenient
way (say one or two source lines) to "borrow" all/most
implementation from another class, would you still feel that
implementation inheritance is still necessary?
I guess I can only at this point answer "it depends". It seems to
me that the current, widely-used implementation inheritance syntax
is pretty much just that: a convenient way to borrow implementation
from another class.
Currently, inheritance of classes "borrows" both the implementation
*and* interface. The thing is that interface and implementation are
borrowed together, and you have to take extra steps if you only want
the implementation or only the interface. I think it might be good
to separate those concepts.
I would have to see what this alternative syntax would look like to
answer more definitively, but it's not clear to me that it'd be
any different in practice from simply inheriting an implementation
directly (assuming that, as with interfaces, a "borrowing" class
still tests "true" for whether it "is" one of these "borrowed"
things...if that's not the case, then I'd say that's a glaring
omission of the proposal).
If the interface "lives" separately from the implementation, then the
borrow can choose to also borrow the interface (or some parent
interface, or some composite interface).
Or, looking at the question from another angle, if it's okay to
"borrow" implementation from another class, what does it matter
whether it was borrowed in the form of inheritance or in the form
of a new type of composition that looks just like inheritance?
Because the borrowing can be more pick-and-choose in the new way,
instead of the all-or-nothing of inheritance. Also, there are times
when your interface maps one-to-one to another class for a few
methods. It could be easier to pick out those methods.
I'm reading this in the Java newsgroup, and perhaps the
"comp.object" crowd has a more thorough academic understanding of
OOP practices and principles than I do. But I admit, based on what
you've written so far I'm not really clear on the distinction
between the way things are now and what you're suggesting they
could be, at least from a practical standpoint.
I guess the main difference is the syntax, but I believe it adds
flexibility too.
/* The following deliberately sets itself strictly within the context of
the Java Programming Language, as it often most beneficial to have a
practical reference to focus the discussion. */
It seems to me all practical examples you gave in this thread are
feasible with the current grammar of Java. There are two discrete
models, one for "borrowing" an interface and one for "borrowing" an
implementation; the first one is called implementing an interface and
the second one extending a class.
The practice of always providing both for all classes isn't ubiquitous,
or even widespread. But, while I grant this may cause you much grief on
diverse occasions, it is simply not an argument against the grammar of
Java, but only potentially against some of its uses.
On the subject of "borrowing an implementation", let me point out that
getting rid of protected modifiers, which you seem to aim at, would
effectively _force_ upon you _all_ the implementation that isn't public
-- so much for "borrowing can be more pick-and-choose".
Anything that was "protected" is still a "public interface" to the
inheritors. You can separate that out quite easily in all the
circumstances I can think of.
The use of composition in a given class is clearly a good idea and
obviously superior to inheritance simply in that you can only inherit
once, but can compose many times. There are various stances one can take
towards composing, from aggressive encapsulating of any functionality
that lurks its head to lazily refactoring en masse. Note, however, that
composition does not replace, or indeed affect, inheritance essentially:
it merely replaces it in the context of one given class. Talking of
composition merely _shifts_ the question of inheritance towards the
classes actually implementing the encapsulated functionality. Now you
may argue that, since through composition you grant the API user means
to replace functionality in transparent manner, you can keep all your
implementations of the encapsulated functionality locked tight. This
would surely be a valid choice, and it may for any given case be
justified or not -- but one thing's for sure and that's that you would
be giving your customers less for their money by prohibiting re-use of
code (unless you make it public throughout, which I don't suppose you'd
advocate).
Since the "protected interface" is specific to an implementation, it
should be called out differently IMO. As far as re-use goes, its
important to limit re-use to things you expect to maintain in the
future. You can still add the hooks to have extensibility in your code,
enabling re-use. You just use a different pattern.
You've been occasionally talking about "clean syntax", "few lines of
code", suggesting your aim was at least partially at some kind of
syntactic sugar. So let me state this: Java boilerplate code is GREAT.
And in my view *any* request for modification of the JLS, the sole
argument in favour of which is that it saves typing, does not deserve
attention (nota bene: shorter syntax is not the same thing as greater
clarity).
I agree short/clever != clear, and this is not in the context of Java,
despite the fact that I posted to cljp :-)
The syntax would be explicit and compact. Having not thought greatly
into it. "MyFoo extends Foo {}" might become "MyFoo implements Foo { Foo
foo; delegate "*" to foo; }
Yes, its a little more typing, but you can replace that "*" with more
specific names, etc... Thats where you get the pick-and-choose. It
also allows inversion-of-control in the inheritance structure. Think "I
want a MyFoo that extends FooBar, and I want another MyFoo that extends
FooLish".
What in my opinion is one of the greatest things about Java is that, at
the basic level, the language features very few denizens: objects,
primitives, classes, interfaces, functions, fields -- that's about it.
With these basic entities, such high-level concepts as callbacks,
closures or concurrent APIs can be built. Entirely transparently so. If
someone wishes to see how it's done, they can, by simply reading the
source code (except for native methods). They can reproduce it freely.
No behind-the-scenes voodoo. Yes, that's it in two words: no voodoo.
I agree with that. I'm not suggesting modifying Java, it would have to
be another (possibly not-yet-existent) language.
At least that's what it was like until they introduced the enhanced
for-loop back in Tiger (I'm not entirely sure it was the first
occurrence, but it's just an example, don't quote me on that). And I can
only hope they won't get through with the closures stuff they're
planning for 1.7. This to me is clearly a step in the wrong direction,
because it /hides/ what's going on. It's voodoo. The enhanced for-loop
takes an Iterable, initialises an iterator, and repeatedly calls next()
while checking hasNext(). We know that because it's written in the
specification. But the point is that nowhere can we see that in plain
Java code anymore.
Now don't get me wrong: the enhanced for-loop is really quite a pleasure
to use, and even I, who am reluctant to it, have found myself making
increasing use of it. But when it comes down to it and I am confronted
with the choice between a short syntax where it's unclear what's going
on and a longer syntax where you see precisely what's going on -- I'm
always going to side with the latter. When you know what you're doing
you can always assess that each bit of effort you provide, no matter how
much of it is overall necessary, is productive; while in the opposite
case you cannot tell whether it may be unproductive or, even worse,
counter-productive.
True, and hopefully the "example" syntax I use above helps to show that
I'm actually exposing more information rather than less. The "delegate"
keyword would expose exactly which methods (by name or whatever) are
being exposed.
df.
Thanks (everyone) for the feedback so far. Even if it appear(s/ed) that
I already made up my mind, it is something that I'm working out for
myself, but want feedback to help confirm or deny my suspicions.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>