From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,5af5c381381ac5a7 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!.POSTED!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Ada requires too much typing! Followup-To: comp.lang.ada Date: Wed, 02 Jun 2010 13:08:24 +0200 Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Injection-Date: Wed, 2 Jun 2010 11:09:18 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="CgeQJFhmVqlm7PSKqn5RPQ"; logging-data="6741"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/1/Xe4ZjaVWU3SLoG3xu+2" User-Agent: KNode/4.4.3 Cancel-Lock: sha1:eQKwikphORS2Z7aiXyc61PzFHhM= Xref: g2news2.google.com comp.lang.ada:12195 Date: 2010-06-02T13:08:24+02:00 List-Id: Luis Espinal wrote: > In article , Alex R. Mosteo > says... >> >>Luis Espinal wrote: >> >>>(...) >>> We have also come to learn that interfaces, the prohibition of multiple >>> inheritance, (...) were not a good idea at all. >> >>Thanks for the elaborate reply. Not expert in Scala/Java so I can't >>comment about most of it. >> >>However, seeing that Ada has just copied Java interfaces, I'd like to >>known a bit more in detail why you say what I quoted, if you have the >>time. I have used interfaces a bit and indeed have some grudges with them, >>but I'd like to know if the situation is worse than I think -- or perhaps >>I'm not using them 100% properly. >> >>Thanks in advance, >> >>Alex. > > Hi Alex - sorry I didn't reply sooner. I've been on the grind at work in > the last couple of days. > > The issue with interfaces (which is not universally accepted among Java > developers) is that they cannot be changed without incurring in changes to > classes implementing that interface. This is a big issue for the way in > which code is developed in Java. Let me try to illustrate: Hi Luis, thanks for the detailed reply. I understand your points clearly. My days of Java are a bit behind so I'm not sure what I'm about to say can be done in Java. In Ada, one could extend an interface adding a new method like this: procedure Moo (This : A) is null; And effectively it won't break any client, since it provides a default "no- op" implementation. It won't work for functions, obviously. In any case, clients would need to recompile, since in Ada land we're not talking of a world of JVMs and dynamic hot-plugging, I presume. This alone (the use of stand-alone executables) may make the problem much less of an issue. Also, not needing to specify defaults to overload a method could be of help? procedure Foo (This : A) is abstract; -- Added in 1st spec procedure Foo (This : A; Bar : A'Class) is null; -- Added in 2nd spec I've done sometimes the thing of having a insulating base class providing some/most of the interface core functionality, but at the same time I realized that this defeats to some degree the point of interfaces, since you can't inherit from two such base classes. In any case I feel your pain about the lot of Java programmers and frameworks ;-) I guess it has its goods and its bads. Alex. > > The common practice in Java is find a platform or framework (some sort of > high-level "virtual" OS for lack of a better word.) Then, either write > your apps on it, or develop another platform on top of it (another, more > refined, more business-specific "virtual" OS. So pretty much we (try to) > gradually refine the architecture of an application via an architecture > pre-defined by the runtime below it. Examples of this are JEE, Spring and > the Eclipse framework (and all the stuff + the kitchen sink that we throw > on top of them.) > > All those layers are typically defined with interfaces (since we don't get > multiple inheritance or mixin/traits). We end up with these long class > hierarchies, and lots and lots of artifacts implementing lots and lots of > interfaces. Libraries and libraries, and platforms and platforms... > without a concept of versions. > > So for example, you have an interface named A that defines a method foo(): > > public interface A { public void foo(); } > > And then you have a large number of classes implementing A, which are > distributed to 3rd parties. A while later, you find you must include a new > method on interface A: > > public interface A { public void moo(); } > > The moment you do that, you render every library that depended on old A > unusable. Either your clients won't be able to compile it, or if they will > get nasty run-time errors. The JVM will even refuse to load the old > classes because they do not conform with the new interface anymore. > > The folks in the eclipse framework, for example, have had to deal with > this problem by implementing "versioned" interfaces and have code deal > with them at run-time: > > public interface A { public void foo(); } > public interface A_1 { public void moo(); } > > class clientOfA { > void dooFooAndMaybeMoo( A someA ) > { > ... > if( someA instanceof A_1 ) > { > ((A_1)someA).moo(); > } > ... > } > > This could get out of hand (specially with sloppy programmers which, in > Java, unfortunately we have too many.) This can also be a concern with > people that develop frameworks and libraries for both external and > internal use. So what we do is that, in addition to implementing an > interface, we typically extend a an abstract base class that can insulate > us from possible changes to the interface: > > public interface A {...} > public abstract class AbstractA implements A {...} > public class ConcreteA extends AbstractA {...} > > If we need to change A, we simply change AbstractA so that clients of A > that extend AbstractA don't get forced to change their source... but that > doesn't do anything for those that still extend A directly. And having an > abstract base class like that defeats the purpose of being able of > creating arbitrary implementations of an interface. > > Other folks deal with that problem by creating Adapters... ending up with > a soup of design patterns going wild. > > Some people still think this is still a better trade-off over C++ styled > multiple inheritance because of the dreaded "diamond" problem. To me (and > this is strictly a personal opinion), it isn't. > > That's a lot of manual shamanism that should be better dealt with > syntactically. We should have had multiple implementation inheritance from > the get-go and just deal with it using the tools of the language and > careful planning. > > I think the Scala guys had the most wonderful of ideas by implementing > Traits. They offer many of the benefits of interfaces while simplifying > the ability of inheriting multiple implementations. The focus is no longer > on building behavior not just with inheritance but also with composition. > I don't need to worry if my object is a-something to that can do a-task; I > just have to worry that it can perform the task. > > I do think that interfaces have been great for specifying contracts. They > enforce an order on things. However, it is important to plan ahead > regarding interface versions. I don't know if this is a big deal in > Ada-land, but in the JVM-land, it has been. > > Please take it with a grain of salt. It is simply my observation, and with > software YMMV from one context to another :) > > - Luis Espinal (luis.espinal@gmail.com)