Re: warning missing

"Thomas Hallgren" <thhal(at)mailblocks(dot)com> writes:

> Yes, it does lack interfaces and no, interfaces are definitely *not* a
> substitute for multiple inheritance.

I assure you that interfaces were put into Java specifically as a substitute
for full-blown multiple inheritance. The normal way to describe interfaces to
a new Java programmer familiar with OOP is "Java supports a limited multiple
inheritance where all but one parent class must be abstract"

(Though even that isn't true with "default implementations" for interfaces
now. Now you basically have full-blown multiple inheritance with a quirky
syntax.)

> An interface is a contract and behind that contract you may have several
> different implementations. JDBC is a good example. PostgreSQL has a JDBC
> driver. So do most other database vendors. The thing they have in common is
> that they implement a set of interfaces that together constitutes a contract
> stipulated by a version of JDBC.

This is a standard technique for other OOP languages as well where you define
an abstract class that defines your API. Any implementation declares itself as
a child of that abstract class in addition to whatever hierachy it would
normally lie in.

> I think we are drifting far apart from the actual subject now. Wether or not
> Common Lisp has interfaces seems somewhat irrelevant to the original
> question.

Well the original question is was whether Java was a "more elaborate" OO
language or a more kludgy half-measure. That interfaces are specifically
intended to be a half-measure to substitute for the full blown OOP feature
that the designers thought was too confusing is a good example. In general
though the design goal for Java was to cherry pick the most useful features of
OOP languages and leave out the features the designers thought were more
dangerous.

Whatever the merits of that approach, it certainly doesn't qualify as the
paragon of OOP languages. The fact that it doesn't allow a certain usage as
far as access privileges could be because it was a good OOP design idea but it
could also simply be because the designers just thought that implementing the
more "correct" model would be too complex or too confusing for beginner
programmers.

Furthermore the situation is further complicated by Java's complex security
model. Since Java was designed with network security in mind there are some
things it cannot support. Not because the programming model is a bad idea, but
because it would lead to security violations in a network environment.

I'm not trying to rag on Java here. (I do that elsewhere:) I just wanted to
point out that using it as an example of how OOP design methodology works only
goes so far. It's a particularly poor example when you're arguing that other
languages are lacking for allowing something Java disallows.

--
greg