Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prototypes Are Not Classes

raganwald.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Prototypes Are Not Classes

#31

Post by Jare »

I've never heard anyone, experienced or newbie, say "JavaScript has classes". People at best will say "You can sort of make classes in JavaScript using objects".

To me a Class has always been "a family of objects with the same structure and behaviour, and a way to create them". Stuff like hiding, constructors, type checking, polymorphism and inheritance are interesting, but secondary details. But then, I was taught OOP using Modula-2 back in '89, so I'm used to the idea that language features and paradigm features need not match 1:1

Re: Prototypes Are Not Classes

#32

Post by pygy_ »

raganwald wrote: post #28
kyberias wrote: post #24

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.

This is the best feedback so far.

How about this for an abbridged version?

"You can add methods to any objects (no metaclass required), and any object can be inherited form, becoming the prototype of its descendants. In other words, any object can perform the job of a class in a class-based language."

Re: Prototypes Are Not Classes

#33

Post by dognotdog »

pygy_ wrote: post #32
raganwald wrote: post #28

Earlier quoted context omitted.

This is the best feedback so far.

How about this for an abbridged version? "You can add methods to any objects (no metaclass required), and any object can be inherited form, becoming the prototype of its descendants. In other words, any object can perform the job of a class in a class-based language."

TL;DR: long winded bad analogy, but maybe helpful

That doesn't sound quite right to me. Not that it is wrong, but maybe looking at it the wrong way?

For the discussion, I propose an object has some state, and can receive messages and send messages in response.

A class is the abstract idea of what an object should be like. To break out the bad analogies, it's like ordering from a restaurant menu. You ask the runtime for an instance of a class. If you want something special, you have to have it put on the menu first. Prototype restaurants have no menus, but they have the dishes on display, and you can order those. Or, if you're so inclined, just point at your neighbours' food and order what that guy's having. If he's eaten half of it already, you'll only get as much as he has left, but luckily you can add combine it with other dishes or ingredients as you go.

You can see that if we put some rules in place about which objects can be copied, and what happens during copying exactly, and we call some special objects classes, and use them to create other special objects we call instances, a prototype-based object system can be made to behave like any class-based object system. If we bake those special rules into the language, we make the computer's job easier with hard-wired shortcuts.

Re: Prototypes Are Not Classes

#34

Post by colept »

kyberias wrote: post #24

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.

It felt like the author was using the post as a cathartic persuasion for why prototypes differ from classes. JavaScript functions are a prototype of a class. Prototyping in JavaScript is an analog to class extensions, with elaborate definitions for private/protected variables. It's a debate over semantics and syntax, and it's useless because the analog to a object oriented class can be done with JavaScript's syntax.

  function MyClass()
  {
  	var self = this;
  	var privateVar = 0;
  	this.getPrivate = function() { return privateVar; }
  	this.setPrivate = function(val) { privateVar = parseInt(val); // restrict type }
  	this.publicVar = "Hello World";
  }

  MyClass.prototype.extension = function() {
  	// Here 'this.publicVar' can be set but 'this.privateVar'
   	// and 'privateVar' are not a valid references.
  }
Long story short, the class analog is semantically no different than the JavaScript prototype when done correctly.

Re: Prototypes Are Not Classes

#35

Post by raganwald »

colept wrote: post #34
kyberias wrote: post #24

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.

It felt like the author was using the post as a cathartic persuasion for why prototypes differ from classes. JavaScript functions are a prototype of a class. Prototyping in JavaScript is an analog to class extensions, with elaborate definitions for private/protected variables. It's a debate over semantics and syntax, and it's useless because the analog to a object oriented class can be done with JavaScript's syntax.…

Encapsulating instance state us not the point, encapsulating the class behaviour is the point. So, if you can make the prototype itself private and modify the prototype with class methods, you have something that prototypes by themselves do not express.

The analogy is not to a private instance variable in Ruby, the analogy is to a class method in Ruby Dutch as define_method.

Re: Prototypes Are Not Classes

#37

Post by egil »

Yet another shallow article describing the difference between prototypes and classes. Does anybody know of more in depth ones that also discusses multi-leven inheritance, polymorphism etc?

Re: Prototypes Are Not Classes

#39

Post by klibertp »

masklinn wrote: post #17
klibertp wrote: post #15

Earlier quoted context omitted.

That's true in JavaScript - there's an Object.create() method, which creates new object with any other object set as prototype: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... There is a problem with accessing prototypes of objects, as they are not exposed to the user and only available through internal property __prototype__ (IIRC). And there's quite a bit of magic involved with constructor prototype…

> There is a problem with accessing prototypes of objects, as they are not exposed to the user Actually, Object.getPrototypeOf was added in ECMAScript 5.1. It's even supported by IE9. > only available through internal property __prototype__ (IIRC) It's an external property (the internal one is `[[Prototype]]`_, and is called `__proto__`. It's non-standard, although all modern browsers implement it (even IE11, but not…

> the internal one is `[[Prototype]]`

I was thinking about this one.

> Actually, Object.getPrototypeOf was added in ECMAScript 5.1.

Wow. Thanks, I wasn't aware of this.

Re: Prototypes Are Not Classes

#40

Post by roel_v »

raganwald wrote: post #27
roel_v wrote: 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…

Yes I did read it, several times even, because I really want to understand it if there is a difference. This is why I could remark what I did - because I've actively looked into explanations of the difference, several times, over the last year or so, and walked away with the same conclusions every time.

My point is that the more I try to understand other people's explanation, the more I think it's just semantics. To put it in your terminology as used in your post, it seems that you are redefining what is commonly and in a broad sense known as 'classes' as 'metaobjects' as a generalization of different ways to implement classes. Which is fine, when you look at the details, but to me the difference doesn't warrant overloading a well-known term like 'class'. (Although I'm still not clear what you'd call a C++ class, if it's not a meta-object as your reply suggests.)

To stay with your C/Pascal vs Smalltalk example - I'd be perfectly fine calling a C struct a 'class' when doing object-oriented C, for example as done in GObject (from GLib, one of the Gnome base libraries), and calling a Smalltalk class also 'class'. 'class' is a malleable OO concept, and its exact implementation isn't all that important or interesting conceptually, and is certainly not tied to one specific implementation of the concept. I still don't see how the Javascript 'implementation' (I put this in quotes because most things in Javascript are just accidents derived from design decisions that put a high premium on ease of implementation, which BTW is usually how I like it, I'm not knocking on JS for that here) of classes is so different that it warrants its own name ('prototype'), suggesting it's completely different from 'classes' (and not only that suggestion, but also people claiming that they're 'very' or 'fundamentally' different - not saying your claim is that strong, I can't really tell from the post, just that some people do).

Post reply on HN