Go and Rust – objects without class (2013)
lwn.net
lwn.net
We _will_ be adding some sort of thing kind of like inheritance to Rust. https://github.com/rust-lang/rfcs/issues/349 is the RFC issue, and it outlines:
* cheap field access from internal methods;
* cheap dynamic dispatch of methods;
* cheap downcasting;
* thin pointers;
* sharing of fields and methods between definitions;
* safe, i.e., doesn't require a bunch of transmutes or other unsafe code to be usable;
* syntactically lightweight or implicit upcasting;
* calling functions through smartpointers, e.g. fn foo(JSRef<T>, ...);
* static dispatch of methods.
The stage it's in is "Niko has a draft RFC that he hasn't published yet." Then there will be discussion, and then implementation.
AST -> LLVM IR
AST -> HIR -> MIR -> LLVM IR
Also, in today's world, for example, we can't stabilize syntax extensions because we'd have to stabilize the AST. But we _can_ stabilize {H,M}IR, much more easily. On the backside, we're very coupled to LLVM right now, and while that probably won't change, if someone wanted to write a backend, they could write their own codegen based off of MIR.
If we're in the "OO" world, and need something analogous to inheritance, I'd rather have an object system with tools for explicit delegation over a system which tries to conflate delegation of behaviour with subtyping. IMHO this is one of the greatest uglinesses of Java (C++ has it too but it's not used much these days.)
> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.
For context, he said this in 2003, at the height of Java's popularity.
"Why is it called Newspeak?
In Orwell's novel 1984, Newspeak was a language that grew smaller over time. Unlike the case of natural languages, for a programming language this is actually a good thing. It is an ideal we strive for - a shrinkable language."
Kay says: Erlang is worth looking at.
Obviously, the 2 to 3 debacle is a constant source of grief, but I don't think that necessarily fits in with the subject at hand: language features that people contest over.
This is easily solvable by making the Container be a generic class "Container of <T extends Widget>". If the language supports such things of course, so not really talking about GTK specifically here. Then a Container<MenuItem> is not a subtype of Container<Widget> (so you're not violating LSP), yet you can still write code that operates on all kinds of containers without giving up any compile-time type checking.
I agree with a lot of the other things in the article, just this was not a particularly good example, because it's more about the shortcomings of a specific language than the shortcomings of subtype polymorphism in general.
If so, the circle is now complete, as we are about to get classes in ES6
I recommend this book: http://www.amazon.com/s?search-alias=stripbooks&field-isbn=9...
"Prototype-Based Programming: Concepts, Languages and ApplicationsMay 14, 1999 by James Noble and Antero Taivalsaari"
The first OO language I learned was the embedded programming language of LambdaMOO ("MOO"), which was used to extend the virtual world. It was prototype based, with a single delegate called the parent subbing in. It still had inheritance, but a different kind.
Oh I know that. It's just that being the most popular programing language in the world helps setting trends, even when you don't invent them.
Messed up scoping rules, and bizarre type coercions, yes, ugly. But the object system I think is nice.
And as Self demonstrated long before Javascript even existed, prototypal inheritance is neither bizarre nor verbose let alone dangerous. As with most other things, Javascript just has a completely mangled version of it for (I can only assume) original implementation simplicity.