Eric, imagine the following scenario: You write a Java class that implements 2 different thirdparty interfaces that are very similar (Thus single impl). One of those interfaces resides in a jar that puts licensing limitations to your code/product. That becomes a problem. Go gives you the option to implement the interface without having the external dependency. Go code will still compile and run in environments where that 3rd party library that hosts the interface is NOT present. It will also support that 3rd party when it is present. But in Java all deployments must have that 3rd party jar and that can limit your commercial options. Working around this requires some acrobatics in Java (separate implementations). This is one of the reasons I like go.
Regards, Ali On Monday, March 29, 2010 at 12:13:37 PM UTC-7, Eric Hawthorne wrote: > > I really think in this discussion there is conflation of the > straightjacket-of-single-inheritance problem with > the explicitness of mention of inheritance issue. > > Java and all single inheritance languages imho are problematic because > they > force arbitrary choice of which properties of things are more > important than > other properties, because only one property dimension at a time can be > the basis > for the next level of class inheritance. That unnecessary choosing is > damaging, because it will > lead to unnatural deep hierarchies, and could lead to a combinatoric > explosion of incompatible > hierarchies that want to be doing/representing the same thing. > > The stated reason for limiting to single inheritance usually amounts > to: "Understanding the > forest of trees, or lattice, of more general mixin types available for > creating or comprehending > the true meaning and functionality of my object (or the aspects of my > object) is just too complex > for most programmers." > > What I would say is that, yes, programming by judicious borrowing of > bits and pieces of meaning and functionality that have already been > provided by others is > going to be, initially, for you the programmer, more difficult. But > the end result will be small snippets > of much more baggage-free re-usable code for yourself and others to > use in the future. > > The solution to the inherent complexity of programming in the middle > of a very large and incremental > mixin-type lattice is better code visualization tools, better class > documentation standards including eiffel-like > class-invariant and pre-post assertions, etc. > > The reason I think that explicit mention of which interfaces/mixins > you are specializing/incorporating is > important, is because being a correct implementor/specializer of a > behaviourally defined type is much more > involved than being method-signature compatible. You must be test- > compatible (invariant-compatible, > method-expected-behaviour-compatible), and header-comment compatible > as well. > You explicitly SHOULD NOT re-comment in your specialized type what it > is that one of your more-general-interface-defined > methods is doing. You should only comment about how it specializes the > general behaviour. Why? > Because comments are as important as code, and maintaining multiple > versions of the same method header comment > in different but related types is as bad as violating the DRY > principle for code itself. > > EOR (End Of Rant) - I know, I'm a hopeless idealist and incurably > naive code romantic. I can always dream though... > > > On Mar 28, 7:38 pm, Peter Froehlich <peter.hans.froehl...@gmail.com> > wrote: > > Hi all, > > > > To paraphrase Knuth: "Premature standardization of interfaces is the > > root of all evil." Some of this sounds like you have not yet lived > > down the "more explicit please" phase we all go through. Not tying > > implementation types to interface types in the language is a Good > > Thing (tm) because it avoids one of the basic problems for > > component-based software: That of *not* wanting to agree on One True > > Interface (to rule them all). Once you get to the point where you have > > to implement two distinct interfaces in one type but now the compiler > > doesn't let you because they happen to disagree on some unimportant > > method, you'll know the pain you've gotten yourself into. True, Go > > already alleviates a little of this, but not enough to make it > > advisable to put explicit declarations back. So please, whoever on the > > Go team reads this thread, don't get tempted into the "but explicit > > interface declarations are better" side of the force. Implicit > > interface compatibility is the way! > > > > Cheers, > > Peter > > -- > > Peter H. Froehlich <http://www.cs.jhu.edu/~phf/> > > Senior Lecturer | Director, Johns Hopkins Gaming Lab > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
