Hacker News Reader

Comment by pcwalton | Hacker News Reader

Inheritance may not make 1.0.

I'm finding that my OO code style these days is very composition heavy with pretty much no inheritance use. I think given Rust's type system, I'm not going to miss inheritance much.

It's a question of performance more than composition.

Please elaborate?

I believe Rust wants inheritance primarily for Servo, because the DOM is defined in terms of inheritance.

Right. Idiomatic Rust prefers composition over inheritance.

Every language in the universe prefers composition over inheritance =P

Not very true.

Some languages prefer inheritance to express is-a relationships and composition to express has-a relationships. Some languages try to shoe horn is-a into being equivalent to has-a, but they usually have trouble expressing non-structural subtyping.

I find that when refactoring code, I often redefine is-a to has-a anyway.

is-a vehicle --> has 4 wheels

Runtime error: Motorcycle lacks 4 wheels

The ones that don't blossom into interface factories which make factory adapters of abstract factories. (I'm looking at you, Java)

For the lack of a nail, throw new HorseshoeNailNotFoundException("no nails!");

For the lack of a horseshoe, EquestrianDoctor.getLocalInstance().getHorseDispatcher().shoot();

(...)

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

If that is the only use case I would rather want another solution to keep the language minimal. Just like the garbage collection was moved to a library.

I think that the core team thought about this long and hard, but it was decided that there was no other solution. A virtual method call to look up some property shared by all the DOM nodes was just too expensive: a constant offset field look up is far far faster.

Can't really do it. I tried. The type checker just plain has to know about inheritance for it to work and be safe.

The good news is that's an extremely constrained sort of inheritance, very unlike traditional OO in that it doesn't have base classes--it's just a special extension to the trait (typeclass) system that allows you to require that structs begin with a certain set of fields. In fact, I don't even call it inheritance these days--I prefer the name "structural constraints".

I think this is a good idea. It seems similar to Go's embedding: http://golang.org/doc/effective_go.html#embedding

The difference is that the base struct can call methods on the derived struct, whereas this is not possible with that kind of struct embedding. This is important for some use cases (e.g. the DOM or the render tree).

I see.

ooh, is this like record subtyping? Have you seen ermine https://github.com/ermine-language or Ur/web? http://www.impredicative.com/ur/

[edit, on #rust it was explained to me that its only for pointers to structs, but thats fine by me]

If anyone is interested, the proposal for Rust is detailed in http://smallcultfollowing.com/babysteps/blog/2013/10/24/sing...

Thanks for the answer, and I think I like your solution to the problem.

Just because people have overused inheritance in the past doesn't mean it's completely useless.

Nobody has said it was useless.

Although with the right language support, it is useless, composition can stand for it (demo: Self)

By that reasoning most programming features are useless (demo: C)

I'm reasonably certain you completely misunderstood my comment, because C definitely isn't an illustration of it.

Ah, news to me. I guess it can be introduced without breaking backwards-compatibility.

Reply on news.ycombinator.com