Live data from Hacker News

Prototypes Are Not Classes

raganwald.com

21–30 of 46 posts

Re: Prototypes Are Not Classes

#21
post #18
post #8

Earlier quoted context omitted.

I'm not sure that's a good idea, because then they'd be made very sad by constructors, by prototypes being something completely different[0], by not having mixins[1], by single-inheritance, by dynamic inheritance[2], by the lack of blocks (and non-local returns), etc… Essentially, by javascript not being a very good Self. [0] IIRC in Self the prototype is the object you copy, objects linked through parent slots are e…

I think that the claims that "JavaScript is like Self" or that "JavaScript is like Scheme" are attempts to legitimize what really isn't a very good language to being with. I think that this is also done out of ignorance, to a large extent. People hear about Scheme and Self being held in high regard, hear about some very vague similarities with JavaScript, and then assume that JavaScript is somehow like Scheme and Sel…

I think that the claims that "JavaScript is like Self" or that "JavaScript is like Scheme" are attempts to legitimize what really isn't a very good language to being with.

I think it can be helpful to say that JavaScript is "like" Scheme if the purpose is to think harder about JavaScript and some of the consequences enabled by its features. On the other hand, I don't think JavaScript really is a Lisp, and it's a terrible idea to say so for the purpose of justifying all of its design choices.

http://raganwald.com/2013/07/19/javascript-is-a-lisp.html

Re: Prototypes Are Not Classes

#22

Earlier quoted context omitted.

So C++ got multiple inheritance wrong... That doesn't mean it must be rejected in all cases.

What are the cases where MI is better than mix-ins or component architectures?

NewtonScript had a neat concept of heterogeneous multiple inheritance: Its "objects" had a prototype-like inheritance chain and a container inheritance chain.

If client-side JavaScript had this design, there would be no need for the DOM to have a special event mechanism that lives outside of method handling: DOM elements would simply have method handlers and the dispatch system would handle prototype and container inheritance.

Re: Prototypes Are Not Classes

#23
post #8

Earlier quoted context omitted.

I'm not sure that's a good idea, because then they'd be made very sad by constructors, by prototypes being something completely different[0], by not having mixins[1], by single-inheritance, by dynamic inheritance[2], by the lack of blocks (and non-local returns), etc… Essentially, by javascript not being a very good Self. [0] IIRC in Self the prototype is the object you copy, objects linked through parent slots are e…

MI still sends shivers down my spine, having spent time in the C++. Just say no.

Beware, Self inheritance is not class-based inheritance, and thus Self MI has very little relation to C++'s MI.

Re: Prototypes Are Not Classes

#25
Every time someone tries to explain why prototypes are so very much not classes, I can't help but come away thinking 'yeah potato/potato - so they're basically the same'. Be it Crockford, this guy, any of the 100 articles you find only when you go looking for it. Sure the nuances between languages are different, big deal - what is called 'class' in a dynamic language is very different from what is called 'class' in C++, yet everybody calls them classes and doesn't go around writing articles about how runtime-modifiable object blueprints really are fundamentally different from those that are set in compile time.

Re: Prototypes Are Not Classes

#26
post #18
post #8

Earlier quoted context omitted.

I'm not sure that's a good idea, because then they'd be made very sad by constructors, by prototypes being something completely different[0], by not having mixins[1], by single-inheritance, by dynamic inheritance[2], by the lack of blocks (and non-local returns), etc… Essentially, by javascript not being a very good Self. [0] IIRC in Self the prototype is the object you copy, objects linked through parent slots are e…

I think that the claims that "JavaScript is like Self" or that "JavaScript is like Scheme" are attempts to legitimize what really isn't a very good language to being with. I think that this is also done out of ignorance, to a large extent. People hear about Scheme and Self being held in high regard, hear about some very vague similarities with JavaScript, and then assume that JavaScript is somehow like Scheme and Sel…

I am aware of that.

On my case, the remark I made had more to do with the fact that many developers tend to be unaware that these concepts also exist in other languages and could learn a bit by seeing them on the languages they originated from.

Even when JavaScript only took tiny details from them.

Re: Prototypes Are Not Classes

#27
post #25

Every time someone tries to explain why prototypes are so very much not classes, I can't help but come away thinking 'yeah potato/potato - so they're basically the same'. Be it Crockford, this guy, any of the 100 articles you find only when you go looking for it. Sure the nuances between languages are different, big deal - what is called 'class' in a dynamic language is very different from what is called 'class' in C…

Did you read TFA or simply fold it into an airplane and launch it towards the dustbin?

1. This is not a dynamic vs. static thing, the languages cited in the article with classes are all dynamic languages. Metaobjects are typically found in dynamic languages like Common Lisp and Smalltalk.

2. The difference between a class as described in this article and a prototype is the same as the difference between a C struct or Pascal record and a Smalltalk object. I do recall people saying "potato/potato" about that when OO was first going mainstream, but I think over time people accepted that encapsulating private state is more than a nuance.

Your Milage May Vary.

Re: Prototypes Are Not Classes

#29

Earlier quoted context omitted.

What are the cases where MI is better than mix-ins or component architectures?

NewtonScript had a neat concept of heterogeneous multiple inheritance: Its "objects" had a prototype-like inheritance chain and a container inheritance chain. If client-side JavaScript had this design, there would be no need for the DOM to have a special event mechanism that lives outside of method handling: DOM elements would simply have method handlers and the dispatch system would handle prototype and container in…

> NewtonScript had a neat concept of heterogeneous multiple inheritance: Its "objects" had a prototype-like inheritance chain and a container inheritance chain.

See also HyperCard/HyperTalk...

Re: Prototypes Are Not Classes

#30

The author has to emphasize that prototypes and classes are a different concept at least five times in the article. Why? Because the explanation is long-winding and weak.

I've read it twice and still can't find the point.
Post reply on HN