The Artima Developer Community
Sponsored Link

Weblogs Forum
Interfaces vs Inheritance (or, watch out for Go!)

21 replies on 2 pages. Most recent reply: Jun 10, 2013 10:55 AM by Oliver Plow

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 21 replies on 2 pages [ « | 1 2 ]
Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: Interfaces vs Inheritance (or, watch out for Go!) Posted: Nov 20, 2009 1:34 PM
Reply to this message Reply
Advertisement
> Forget generics. Go doesn't even have exceptions.

Interestingly enough, both language features are tough to add afterwards. There will be tons of code that is not very type-safe (because there are no generics and type-safe containers) and even worse not exception-safe.

Adding exceptions as an afterthought would break so much code that it is not even funny. If they don't introduce them before going out of the "experimental" phase, they'd better leave them out forever.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Interfaces vs Inheritance (or, watch out for Go!) Posted: Nov 20, 2009 5:56 PM
Reply to this message Reply
> Too bad about Dylan. If Apple had been investing in it
> all these years, I'm sure it would be a really nice
> environment to program in these days.

"i'm not dead yet!"

http://www.opendylan.org/

(ok, but i totally agree that it isn't the kind of language you can convince your cto and anything other than a teeny tiny startup to use. much like CAL. more so than scala or even clojure.)

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: Interfaces vs Inheritance (or, watch out for Go!) Posted: Nov 22, 2009 10:13 AM
Reply to this message Reply
> > Too bad about Dylan. If Apple had been investing in it
> > all these years, I'm sure it would be a really nice
> > environment to program in these days.
>
> "i'm not dead yet!"
>
> http://www.opendylan.org/
>
> (ok, but i totally agree that it isn't the kind of
> language you can convince your cto and anything other than
> a teeny tiny startup to use. much like CAL. more so than
> scala or even clojure.)

I'm well aware of opendylan, and it's great that Functional Objects opened up their code. But unfortunately opendylan consists of about 3 or 4 guys at any one time, hacking on it after the kids go to bed for an hour or so (if that).

The jist of my point was that Apple had starting providing betas of a really great environment for a really expressive language before Java was even really known. And it makes you wonder where it would be today if the NeXT folks hadn't pushed it out.

Toshiro Go Sakata

Posts: 1
Nickname: tgos
Registered: Jan, 2010

Re: Interfaces vs Inheritance (or, watch out for Go!) Posted: Jan 5, 2010 10:37 AM
Reply to this message Reply
I'm not convinced that interfaces are always better than inheritance. Here is a typical example against that theory:

I create an interface that has two methods, I implement one class that is based on the interface, someone else implements another one. Everything works as expected. I find out that the interface needs a third method. I add it to the interface and I add to my class. The other person does not - BANG, I broke third party code by just changing my interface. The program may not even start, a VM might see the missing interface method and refuses to even open the application.

I create no interface, but I create a class other users can inherit of. It has two methods that I implement. Someone else inherits from my class, overrides both methods. I decide that my class needs another method, so I add. The other person has not overridden it, but the method is there. His code may or may not work as expected, because he has not overridden the third method, but at least it will start and do something and maybe it will even work correctly, because there was no need to even override this method.

The inability to just change interfaces as desired, because any change can break anything else in the world, has lead to the fact that interfaces can never be changed, once released, but are usually extended by a V2 version (or similar stupidity). And this is not good code or design IMHO.

Another sample where inheritance is better? Okay:

I write an interface and implement it in my class. Some other coder is quite happy with my class, there is just one method (out of 50) he would like to change... still, he cannot use my class. He either must implement all 50 methods itself (duplicating huge amounts of my efforts) or he needs to encapsulate my class internally, forwarding all calls to 49 methods to an object of my class, except for one method, that he implements himself. This causes a speed penalty for 49 method calls (as each method call is just a redirection to another method call).

If he inherits from my class, he can just override this one method, which is much less work, and there will be no speed penalty, because each method call goes directly to my method, except for the one that was overridden.

The second sample can be solved by a clever compiler (that automatically forwards calls to an internal method), a clever VM that detects pure forward method calls and a good JIT compiler that eliminates those in the generated native code - it's just all more work, but possible. I know no solution to the "interfaces cannot change" problem. Considering how often a new release of some framework adds methods to already existing objects, if those were all just interfaces, every new release of a framework, SDK, and the like will break pretty much every existing code in the wild.

Michele Simionato

Posts: 222
Nickname: micheles
Registered: Jun, 2008

Re: Interfaces vs Inheritance (or, watch out for Go!) Posted: Jan 7, 2010 12:00 AM
Reply to this message Reply
> I'm not convinced that interfaces are always better than
> inheritance. Here is a typical example against that
> theory:
>
> I create an interface that has two methods, I implement
> one class that is based on the interface, someone else
> implements another one. Everything works as expected. I
> find out that the interface needs a third method. I add it
> to the interface and I add to my class. The other person
> does not - BANG, I broke third party code by just changing
> my interface. The program may not even start, a VM might
> see the missing interface method and refuses to even open
> the application.
> I create no interface, but I create a class other users
> can inherit of. It has two methods that I implement.
> Someone else inherits from my class, overrides both
> methods. I decide that my class needs another method, so I
> add. The other person has not overridden it, but the
> method is there. His code may or may not work as expected,
> because he has not overridden the third method, but at
> least it will start and do something and maybe it will
> even work correctly, because there was no need to even
> override this method.

There is no such problem. I can add a third method to my *implementation* of the interface without changing the
abstract interface and the situation is the same as in
the inheritance case.

> The inability to just change interfaces as desired,
> because any change can break anything else in the world,
> has lead to the fact that interfaces can never be changed,
> once released, but are usually extended by a V2 version
> (or similar stupidity). And this is not good code or
> design IMHO.

The whole purpose of interfaces is to communicate to other people the *minimal* requirements their objects must have
to be usable by other code. Sometimes people publishes bad interfaces, right, but there is no other way to communicate, unfortunately.
Notice that even a piece of paper with the list of public methods is an interface, no need to have them in the language. Without that piece of paper/interface documentation how would you communicate?

> Another sample where inheritance is better? Okay:
>
> I write an interface and implement it in my class. Some
> other coder is quite happy with my class, there is just
> one method (out of 50) he would like to change... still,
> he cannot use my class. He either must implement all 50
> methods itself (duplicating huge amounts of my efforts) or
> he needs to encapsulate my class internally, forwarding
> all calls to 49 methods to an object of my class, except
> for one method, that he implements himself. This causes a
> speed penalty for 49 method calls (as each method call is
> just a redirection to another method call).
>
> If he inherits from my class, he can just override this
> one method, which is much less work, and there will be no
> speed penalty, because each method call goes directly to
> my method, except for the one that was overridden.

You are thinking in an inheritance-oriented way. I suggest you to study idiomatic code in languages which do not rely on inheritance and you will see that this problem in practice do not arise, since people use different designs than the template pattern. Maybe I should write a post on that, it is a common complain.

Andrew Black

Posts: 1
Nickname: apblack
Registered: Jul, 2010

Re: Interfaces vs Inheritance (or, watch out for Go!) Posted: Jul 16, 2010 5:29 PM
Reply to this message Reply
> I also planned to write a paper about
> interfaces, to explain how things should be done ... I
> never wrote it [in part because] I needed a language with
> interfaces done right to explain what I had in mind

Does Emerald "do interfaces right"? If you can get away from the idea that anything invented before the year 2000 must be irrelevant, you might take a look. Emerald was designed around 1984, and has interfaces, subtyping (called conformity), and parameterized types (now called generics). But no inheritance.

Oliver Plow

Posts: 3
Nickname: oliplow
Registered: Dec, 2012

Re: Interfaces vs Inheritance (or, watch out for Go!) Posted: Jun 10, 2013 10:55 AM
Reply to this message Reply
> You are thinking in an inheritance-oriented way. I suggest
> you to study idiomatic code in languages which do not rely
> on inheritance and you will see that this problem in
> practice do not arise, since people use different designs
> than the template pattern. Maybe I should write a post on
> that, it is a common complain.

Let's have a look at some sample Go code taken from http://www.infoq.com/articles/google-go-primer:

package main

import "fmt"

type Base struct {}

func (Base) Magic() { fmt.Print("base magic") }

func (self Base) MoreMagic() {
self.Magic()
self.Magic()
}

type Foo struct {
Base
}

func (Foo) Magic() { fmt.Print("foo magic") }

func main() {
f := new(Foo)
f.MoreMagic()
}

f.MoreMagic() will print "base magicbase magic" and not "foo magicfoo magic ". This is because without inheritance, there is no method overloading. Let's a look at some code to fix this:

package main

import "fmt"

type Magician interface {
Magic()
}

type Base struct{
magician Magician
}

func (Base) Magic() {
fmt.Print("base magic")
}

func (self Base) MoreMagic() {
self.magician.Magic()
self.magician.Magic()
}

type Foo struct {
Base
}

func (Foo) Magic() {
fmt.Print("foo magic")
}

func main() {
f := new(Foo)
f.magician = f
f.MoreMagic()
}

This will now print "foo magicfoo magic". So every time we add a method to some base class some other class delegates to and that method combines already existing methods, we have to reimplement that method in all other classes that also delegate to that base class.

The reason things are like that in Go is that Go is a modernized C and you would have to do things just the same way in C. It has IMHO little to do with delegation making inheritance redundant. Go simply doesn't go beyond what C does.

When in C a struct needs to refer to fields in a another struct, you add a pointer in your struct that points to that other struct. Delegation in Go is a mechanism that frees you from doing the plumbing work for this yourself manually. Again, IMHO it has little to do with delegation making inheritance redundant.

-- Oliver

Flat View: This topic has 21 replies on 2 pages [ « | 1  2 ]
Topic: ScalaTest 2.0.M6 Preview Previous Topic   Next Topic Topic: Simplicity Before Generality, Use Before Reuse


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us