Go and Rust – objects without class (2013)(lwn.net)
lwn.net
Go and Rust – objects without class (2013)
https://lwn.net/Articles/548560/
33 comments
Is there any schedule for when that'll be worked on? It's a big thing I'm waiting on for porting some UI toolkit work to Rust.
Everyone is working on HIR/MIR at the moment, because it will enable a lot of different kinds of work to happen in parallel after it lands.
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.
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.
What's HIR/MIR?
To build on the other answer, right now, the compiler does
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.
AST -> LLVM IR
Which works, but you have to do all of the compilation passes and static checks on the AST. After this work is done, we'll have AST -> HIR -> MIR -> LLVM IR
These two intermediate representations will make it easier to write frontends and backends to Rust, as well as making it easier to implement various optimization and analysis passes, and making them faster.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.
Different AST representations in Rust compiler - high level and middle level.
Unfortunately, almost nothing "in the pipeline" has any kind of schedule attached to it. The best you might get is a partial ordering on the priority of features.
Smalltalk-72 (well, Smalltalk before Smalltalk-76) did not have inheritance. And I believe Alan Kay is on record indicating he felt that inheritance in Smalltalk had often been misapplied or not well understood, and spoke well of Self and other experiments with classless object models.
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.)
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.)
Yes, Alan Kay was very clear that he does not believe inheritance to be a key part of object-oriented programming.
> 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.
> 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.
Yeah I also seem to remember him saying (maybe on a Squeak mailing list or somewhere else... many moons ago when I followed this kind of thing) that Smalltalk 72 was his personal favourite Smalltalk.
Reminds me of Newspeak:
"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."
http://www.newspeaklanguage.org/
"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."
http://www.newspeaklanguage.org/
Erlang probably also counts.
http://blog.blainebuxton.com/2003/09/erlang-i-got-following-...
Kay says: Erlang is worth looking at.
Kay says: Erlang is worth looking at.
It's refreshing to write software with these languages and not having to deal with standard OO.
> Both Rust and Go add some new and interesting ideas which, like languages before them, will initially attract programmers, but will ultimately earn both languages their share of derision, just as there are plenty of detractors for C++ and Java today.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses"
--Bjarne Stroustrup
That's a bad cop out. There are widely used languages like c# and python that cause very little whining.
Define "very little"...
Language feature-wise, I think python 3 has very little complained about it. The chief complaints about python I hear are anything to do with packaging software and multi threading the second of which will hopefully be fixed by 3.7.
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.
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.
>If this restriction were to be encoded in the type system, GtkMenuShell would not be a true subtype of GtkContainer as it cannot be used in every place that a GtkContainer could be used — specifically it cannot be the target of gtk_container_add(myButton).
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.
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.
Structure embedding is not inheritance. It's just structures as first class types. This becomes clear as soon as you create a structure that contains two strings.
Javascript's influence?
If so, the circle is now complete, as we are about to get classes in ES6
If so, the circle is now complete, as we are about to get classes in ES6
Classlessness in OO systems was around a long time before JS was even conceived of.
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.
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.
Classlessness in OO systems was around a long time before JS was even conceived of.
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.
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.
I find it unfortunate that lack of classes is seen as some chief defect of JS. It's actually one of the things I like about it.
Messed up scoping rules, and bizarre type coercions, yes, ugly. But the object system I think is nice.
Messed up scoping rules, and bizarre type coercions, yes, ugly. But the object system I think is nice.
Well , not anymore since ES2015 has classes,class inheritance,super and co. Prototypical inheritance is bizarre, verbose and dangerous.
ES2015 doesn't have classes, it has a class statement which desugars to prototypal inheritance.
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.
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.
[deleted]
Yes I find it very unfortunate that 99% of people's exposure to 'prototype inheritance' is JS's rather inelegant form of it. Though like many things with JS if you are disciplined it can be used elegantly.
And Smalltalk's on JS. ES6 classes are just syntax on prototypes, they don't actually change the underlying object model.
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:
That being said, we don't expect this to ever be the primary method of modeling in Rust. It's just that sometimes, you do have something which is legitimately represented by inheritance or something like it.