5 ms·

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

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.

raganwald 13y ago
This is the best feedback so far.
- pygy_ 13y ago
  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."
  - dognotdog 13y ago
    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.
  - xmonkee 13y ago
    How about this: "In a class based model, skeletal templates (classes) serve as object factories, with something general (the class) serving as the starting point of something specific (an object). In a prototype based model, the prototype object provides a fully fleshed out starting point for other objects, with something specific (the prototype) serving as the starting point of something even more specific (the inheriting object)"
avdd_ 13y ago
I've read it twice and still can't find the point.
colept 13y ago
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.
- raganwald 13y ago
  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.

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.

raganwald 13y ago

This is the best feedback so far.

pygy_ 13y ago
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."
- dognotdog 13y ago
  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.
- xmonkee 13y ago
  How about this: "In a class based model, skeletal templates (classes) serve as object factories, with something general (the class) serving as the starting point of something specific (an object). In a prototype based model, the prototype object provides a fully fleshed out starting point for other objects, with something specific (the prototype) serving as the starting point of something even more specific (the inheriting object)"

avdd_ 13y ago

I've read it twice and still can't find the point.

colept 13y ago

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.

raganwald 13y ago
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.