Talk:Prototype-based programming

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Wikipedia license non-compliance?[edit]

The first sentence of the second paragraph of this article was lifted with only a minor change of punctuation from this Mozilla Developer Network article: [1] Here's the license on that page, CC A/SA which I believe means that Wikipedia must cite that page. I'm sure someone will look into this. [2] Psychlohexane (talk) 21:18, 26 September 2011 (UTC)[reply]

A few sections...[edit]

A few sections of this article confuse the concepts of prototype-based and classless programming. Prototype-based programming is based on cloning existing prototypical objects. It is a special case of, but not the same as, classless programming. A few parts of the article, particularly the ones mentioning JavaScript, get this distinction wrong. While JavaScript is classless it is not prototype-based since there are no prototypes and no cloning. The JavaScript language does include a concept of prototypes but in a very different sense from the traditional one. Plesner 19:12, 25 March 2007 (UTC)[reply]

What is information hiding?[edit]

What is information hiding?

Use the wikipedia: Information hiding Wouter Lievens 17:06, 1 May 2005 (UTC)[reply]

Uses[edit]

Aside from JavaScript, which PBL's are used outside academia? Wouter Lievens 17:07, 1 May 2005 (UTC)[reply]

The MOO programming language in MOO.Ryandaum 01:32, 11 January 2006 (UTC)[reply]

On another note, this page could do with a section contrasting different 'styles' of prototype-based languages; off the top of my head, there is: delegation, inheritance and cloning. I will try to write something up at some point.Ryandaum 01:32, 11 January 2006 (UTC)[reply]

Not sure why Ruby was added as a specific example of a OO language that allows alteration of classes during runtime, as I can think of several: Python, Lisp (with CLOS), etc. I worry there's a bit of advocacy going on here?Ryandaum 01:47, 18 February 2006 (UTC)[reply]

In the 'Delegation' section, it says:

Unlike the relationship between class and instance in class-based object-oriented languages, the relationship between the prototype and its offshoots does not require that the child object have a memory or structural similarity to the prototype beyond this link. As such, the child object can continue to be modified and amended over time without rearranging the structure of its associated prototype as in class-based systems

This is just wrong: not all class-based systems require the structure of the "class" to be changed. (e.g., in python you can do whatever you want to an instance without changing the class at all) .. this is more a distinction between a statically vs dynamically typed systems. —Preceding unsigned comment added by 98.212.194.168 (talk) 17:05, 4 June 2010 (UTC)[reply]

History of prototypes[edit]

Everyone seems to consider Self to be the first prototype-based language, but in actual use among a large number of people, MOO must pre-date it substantially. Note that both languages came out of Xerox PARC, so I'm not suggesting that Ungar and Smith's Self research didn't pre-date MOO, but MOO was in active use as of about 1990, and my sense of Self (hmm) is that it didn't become very "real" until a fair bit later. Anyone with a better sense of the historical details care to clarify this?

MOO did not in fact come out of Xerox PARC. (I'm an early MOO user, and have heavily edited that article as well as this one). MOO was created by Stephen White before Pavel Curtis took it over and called it LambdaMOO. And AFAIK LambdaMOO was never truly an official PARC research project, but instead something that was given hosting by PARC and maintained by Pavel.Ryandaum 01:22, 10 May 2006 (UTC)[reply]

Curtis' chapter in the Haynes & Holmevik book suggests that what White had created was pretty patchy before Curtis got hold of it. Curtis was working at PARC as on programming languages, so he clearly had a legitimate interest in developing the language and the libraries, though I agree that it appears to have not been an "official" PARC project. The question remains... where did the prototypes architecture come from? From White? In which case he is quite an innovator -- wasn't he a Waterloo student at the time? JMax 03:05, 27 June 2006 (UTC)[reply]

This would be a good thing to look into. White's later work (CoolMUD) definitely had a prototype model, and a more refined one at that. I also don't know if MOO was consciously prototype-oriented at the time, or if the design choice was simply dictated by the way MUDs operate (physicality of objects). Certainly MOO and its early documentation never use the word 'prototype' anywhere, and delegates are referred to as 'parent', etc. Also, do you have a reference for the assertion that Curtis was working on programming languages at PARC? I have never seen a description of the actual work he was doing there. These might be good questions to ask White, I do have his email address somewhere. I will try to remember to look into it.Ryandaum 23:03, 28 June 2006 (UTC)[reply]

WELLL... Not a lot of detail, but in the chapter "Not Just a Game: How LambdaMOO Came to Exist and What it Did to Get Back at Me", in C. Haynes & J. R. Holmevik (Eds.). High Wired: On the Design, Use, and Theory of Educational MOOs (Ann Arbor: U Mich Press 1998), Curtis writes that he was leading the SchemeXerox project at PARC at the time, and that the project had slowed down to a crawl, giving him the opportunity to first discover MOO and then devote a bunch of (unofficial) time to it. On discovering MOO, he wrote:

I recognized immediately that, in some form at least, there must be a user-accessible programming language here. Being a professionally trained programming-language designer, I have a sometimes morbid fascination with the design efforts of amateurs; I wanted to see if, maybe, these folks had done something interesting... (p. 26)

He then goes on to praise White's design for originality and good 'fit' to the domain, and reports that he and White worked together to fix bugs and work on the "evolution of his language" (p. 29). In early 1991, Curtis says that his annual performance appraisal at PARC forced him to reconcile himself to the fact that MOO had chewed up an entire quarter, and that he would up making promises to get back to SchemeXerox (p. 32). JMax 17:09, 3 July 2006 (UTC)[reply]

Ah, interesting. From http://hci.stanford.edu/seminar/abstracts/91-92/920108-curtis.html

Biographical Sketch: Pavel Curtis has been a member of the research community at the Xerox Palo Alto Research Center since 1983, during which time he has worked on aspects of the Smalltalk-80, Interlisp-D/Xerox Lisp, and Cedar programming environments and on other projects mostly related to the design and implementation of programming languages. His current activities include the design, implementation, and maintenance of an extensible and programmable multi-participant text-based virtual reality called LambdaMOO and leadership of the SchemeXerox project, which aims to produce an advanced programming environment based around a new implementation of the Scheme programming language suitable for use in large-scale software systems.

I must note that there is a very obvious functional programming influence in LambdaMOO; as with prototypes, whether this was a White or Pavel influence or both, I do not know.Ryandaum 00:16, 5 July 2006 (UTC)[reply]

Example of object creation[edit]

Could someone add an example to clarify the difference between class based and prototype based object creation/cloning?--82.92.191.87 16:44, 29 June 2006 (UTC)[reply]

Unsourced statements[edit]

Can someone please add a source for the following claim:

For example, Lisaac compiler produces code almost as fast as C. Tests have been run with a MPEG-2 codec written in Lissac, copied from a C version. These tests show the Lisaac version is 1.9% slower than the C version with 37% fewer lines of code. --Dzhim 00:14, 7 July 2006 (UTC)[reply]

Or this:

"Prototype-based programming is often associated with particular schools of thought in cognitive psychology which emphasize prototypes or exemplars as key attributes of the learning process." Sounds like BS to me.

--Lingwitt 05:02, 29 January 2007 (UTC)[reply]

Confusing sentence[edit]

The article says this:

With class-based languages, objects come in two general 
types. Classes define the basic layout and functionality 
of objects, and instances are "usable" objects based on the patterns of a 
particular class.

What does this mean? First of all type has a specific meaning in Computer Science, so that term shouldn't be used. Is this sentence trying to say that an object has two facets—an instance and a class? I'm just confused.

...

I agree, the wording is bad -- I based it on some aspect of the word of the original article, which was talking about low-level pointers/offsets/vtable issues, which I felt was not appropriate. Type is a poor choice of word -- "kind" would be a better word. The sentence isn't saying that an object has two facets, but that a class can be seen as a a kind of object itself, a 'special' object (see Smalltalk's metaobject protocol, for example.) We need to come up with some better wording here.Ryandaum 23:31, 8 August 2006 (UTC)[reply]

I see. I always considered objects to be instances of a class. Even the class object is an instance of metaclass in Smalltalk. I think that distinguishing between classes and instances is misleading because they are all instances. The only difference is that a class object is a special kind of object. Am I right in saying that in OO, object and instance are synonyms?--Andrew Eisenberg 05:40, 9 August 2006 (UTC)[reply]
Well the entire point of the prototype article is to point at systems that don't have instances versus classes, but only have ... objects. The word instance implies a 'blueprint', which prototype systems do not have.Ryandaum 20:15, 9 August 2006 (UTC)[reply]
OK, then. How about something like this as a rewrite:
In OO systems, all objects are instances of a class.  A class 
defines a kind of blueprint for an instance, defining its  
structure and functionality.  In prototype-based systems, an
object is simply an object and can be configured with any kind of
structure and functionality as desired.
I'm just taking what you said above and rewording it slightly. It's better, I think, but can still use some work. Andrew Eisenberg 22:26, 9 August 2006 (UTC)[reply]
I would also like to critisize a part of the article. In the section about criticism, Javascript is mentioned as a "good" example of prototype based programming. IMHO, I think Javascript is a BAD example of prototype based programming. In fact I find Ruby (which is class based) much more open and accessable than Javascript, and I really can not understand how Javascript is becoming a role model for prototype based programming. In fact, I think Javascript does everything wrong. Maybe the section about criticism about prototype based programmign could become less centric on Javascript, and instead generalized more readily, including Languages like Io and Self more rather Javascript. —Preceding unsigned comment added by 80.108.103.172 (talk) 13:25, 20 February 2009 (UTC)[reply]

Incomplete Prototype implementation reference for ruby[edit]

The linked prototype-script for ruby does not do what it claims to do and is no complete prototype implementation. When cloning a proto, it does copy the attribute of the source to the destination, but if an attribute links to another object - like an Array - it is not copied. Thus, after copying such protos, they will share the same secondary objects. If you add something to an Array in Proto A, it is also there in Proto B - and the other way around. Therefore, ruby currently has no properly working Prototype-Implementation and therefore should not be listed as supporting Prototypes. --82.141.50.118 (talk) 02:08, 1 April 2008 (UTC)[reply]

E4X[edit]

In the section languages E4X is reported as a prototype based language, but it's an extension of ECMAScript and not an ECMAScript derived language.

Luca.greco (talk) 17:46, 14 January 2009 (UTC)[reply]

Critisism[edit]

Lots of 'weasel wording' and other issues in the critisism section. It appears to have been rewritten to remove all the critisism and instead focus on counteracting arguments. The last paragraph is especially bad - how can a common critisism be that the people making the critisisms are ignorant? It doesn't make any sense. The entire section reads like someone's personal opinion and not fact.

208.118.138.213 (talk)

The whole page suffers from overspecialized points of view. I would not dare to say which language feature prototype-based inheritance, much less "true" prototype-based inheritance.

An issue should come up somewhere, probably in the criticism section: that of the circular reference.( A is prototype of B, and B a prototype of A). Example of this concern ECMA-262.

ECMA-262 4.2.1 gives a normative definition for JavaScript/ECMAScript:

"Every object created by a constructor has an implicit reference (called the object's prototype) to the value of its constructor's prototype property. Furthermore, a prototype may have a non-null implicit reference to its prototype, and so on; this is called the prototype chain. When a reference is made to a property in an object, that reference is to the property of that name in the first object in the prototype chain that contains a property of that name."

"Every object created by a constructor" means in fact "Every object": section 11.1.5 defines ObjectLiteral : " { } is evaluated as follows: Return a new object created as if by the expression new Object() where Object is the standard built-in constructor with that name."

Given this definition, the issue of circular reference appears clearly. It is also a concern of ECMA-262 8.6.2: "Every Prototype chain must have finite length (that is, starting from any object, recursively accessing the Prototype internal property must eventually lead to a null value)." — Preceding unsigned comment added by Polbrian (talkcontribs) 10:33, 26 September 2011 (UTC)[reply]

Polbrian (talk) 10:34, 26 September 2011 (UTC)[reply]

Removal of LPC[edit]

The OO implementation of LPC is not prototype-based. Objects are defined by and instantiated from classes, and inheriting classes does not transfer state data to child objects. —Preceding unsigned comment added by 129.120.93.76 (talk) 16:32, 12 March 2010 (UTC)[reply]

?[edit]

Unlike the relationship between class and instance in class-based object-oriented languages, the relationship between the prototype and its offshoots does not require that the child object have a memory or structural similarity to the prototype beyond this link.

I'm confused, classed based OO languages do not require any constraints on memory layout. Someone fix this paragraph. —Preceding unsigned comment added by 99.224.97.6 (talk) 13:16, 16 May 2011 (UTC)[reply]

ActionScript[edit]

Yes it is true that ActionScript is a prototype-based language, but the version that were prototype-based are so old and rarely used now (I believe only 1.0), that 1.0 should really be added to it. Actionscript 3.0, which has been the de facto standard for years now, is a fully class-based OO language that has more in common with Java or C# than a language like Javascript. This could be a source of confusion. 76.30.21.39 (talk) 20:54, 14 October 2011 (UTC)[reply]

Does that mean that newer versions don't use prototypes, or have they just been sidelined by classes? —82.36.30.173 (talk) 05:41, 10 November 2012 (UTC)[reply]

Wrong code-example[edit]

The first code-example (in JS) is definitely wrong:

See this section (1):

var bar = {two: "two", three: 3};

And see this section (2):

bar = Object.getPrototypeOf(foo);

1. Section (2) is simply re-assigning `bar`, so, why is Section (1) neccessary?

2. In Section (2), `Object.getPrototypeOf(foo)` returns `Object.prototype`, which have no such property call "one", "two" or "three"

It makes nonsence, and wrong, please delete it. — Preceding unsigned comment added by Khải (talkcontribs) 12:49, 7 November 2015 (UTC)[reply]

Fruit example in intro[edit]

In the intro section, there's the "Let's use the idea of "fruit" as one example..." paragraph. The point of view it's speaking from and overall wording and tone feels different to the rest of the article. I think it should be rewritten, reworded, or otherwise edited in some way. Jchen57 (talk) 00:30, 13 June 2017 (UTC)[reply]

I've tried to reword it to get rid of the "Let's use...", but I'm still unsure if that kind of paragraph is needed in the head. I'd think about moving it to under "features", or even getting rid of it entirely. A picture of a dead fish (talk) 03:31, 26 July 2017 (UTC)[reply]

Removed contentious description of contatenation as "pure prototyping"[edit]

There was no justification for calling concatenative prototyping "pure prototyping". Kevo, a relative newcomer (and a dead language, it seems), seems to be the only language to make this the default implementation of prototyping (as opposed to an option that can be implemented by the developer in any prototyping language). This page (and a few stackoverflow pages that reference it) seems to be the only place where the term is used with this meaning. Itsbruce (talk) 11:50, 24 June 2018 (UTC)[reply]