

Prototypes are Objects - shawndumas
http://raganwald.com/2015/06/10/mixins.html

======
seanmcdirmid
This is an old debate that has been resolved (at least back then) since what
is called "the Treaty of Orlando" at OOPSLA 1987; here is a public paper
written afterward:

[http://web.media.mit.edu/~lieber/Publications/Treaty-of-
Orla...](http://web.media.mit.edu/~lieber/Publications/Treaty-of-Orlando-
Chapter.pdf)

Abstract:

> For the past few years, researchers have been debating the relative merits
> of object-oriented programming languages (OOPLs) with classes and
> inheritance as opposed to those with prototypes and delegation. It has
> become clear that the OOPL design space is not a dichotomy. Instead, we have
> identified two fundamental mechanisms, templates and empathy, and several
> different independent degrees of freedom for each. Templates create new
> objects in their own image, providing guarantees about the similarity of
> group members. Empathy allows an object to act as if it were some other
> object, providing sharing of state and behavior. Smalltalk, Actors,
> Lieberman''s delegation system, Self, and Hybrid each take differing stands
> on the forms of templates and empathy. Some varieties of template and
> empathy mechanisms are appropriate for building well-understood programs
> that must be extremely reliable; others are better suited for rapidly
> prototyping solutions to difficult problems. The differences between
> languages designed for each of these application domains can be recast as
> the differences between support for anticipated vs. unanticipated sharing.
> One can even ascribe the ascent of object-oriented programming to its strong
> support for extension instead of modification. However, many kinds of
> extension still remain difficult. The decomposition of an object-oriented
> language into template and empathy mechanisms and the degree of support for
> extension provided by the forms of these mechanisms provide a solid
> framework for studying language design.

~~~
jivardo_nucci
"Empathy? Empathy? We don't need no stinkin' empathy!"

Uh, perhaps you meant "delegation"? No one uses the term "empathy" in
reference to any OOP languages AFAICT except the authors of that non-text
searchable paper written in 1987 that you reference. Even if _they_ used the
term "empathy" it would have been better to use "delegation" in describing the
paper, because to not do so reduces the empathy of your audience.

[I am thorry, I could not resithd, but muth go now becauth I have an
appointment with the delegation of the ambatthador at the the U.S. empathy].

------
barrkel
Mixins need to be used with great care in dynamically typed languages. It's
extremely easy to introduce dependencies on symbols in the class you're
getting mixed into, and in larger projects it's not difficult to get name
clashes between methods defined in different mixins, so that earlier mixins
get clobbered by later mixins.

From my experience, I'm not a big fan of mixin-heavy development. Mixins need
a lot of discipline. A mixin probably shouldn't exist if it doesn't have at
least two, if not three different target classes it is mixed into.

I've seen mixins used for almost evil things in Rails. When mixins start
adding before filters to controllers, disturbing amounts of magic can occur.
You can end up needing to research a whole dependency dag and details of its
implementation before you can understand a single method that may not refer to
a mixin by symbol at all.

~~~
braythwayt
TFB(ook) by TFA(uthor) of TFA(rticle) discusses the issues with open
recursion, and describes a pattern for using ECMAScript 2015 symbols to
address this exact problem:

    
    
        const books = Symbol(“books”);
    
        const BookCollector = {
          addToCollection (name) {
            this.collection().push(name);
            return this;
          },
          collection () {
            return this[books] || (this[books]= []);
          }
        };

------
rootedbox
"JavaScript’s choice to build OOP out of simple parts–objects, functions, and
properties–makes the development of new ideas possible."

They did things like every other language basically. Everything is a pointer,
and types are just abstractions we placed on things. So Functions, Objects,
Properties can be passed around just like any other variable or even merged
together fairly easily. Some languages hide this from you.. some require that
you ask very nicely if you do things like this(pascal).. and others simply
don't care what you do(c++).

------
AnEngineer
While the observations I am about to make likely will be down-voted by
some/many in this forum, perhaps even be viewed as heresy, I am compelled to
present them on the chance that it helps some to understand what JavaScript
objects truly are.

TL;DR JavaScript "objects" are nothing more than a <a
href="[https://en.wikipedia.org/wiki/Hash_table">Hash](https://en.wikipedia.org/wiki/Hash_table">Hash)
map</a>.

From the article:

> Prototypes in JavaScript are “just objects,” and since they are “just
> objects,” we can add, remove, or modify methods of the prototype by adding,
> removing, or modifying the functions bound to properties of the prototype.

They are not "just objects." In fact, symantically they are nothing more than
a hash map (a.k.a. hash table, dictionary)[1]. The above quote from the
article clearly indicates this fact as, if we peform three simple keyword
substitutions, the sentence reads thusly:

Prototypes in JavaScript are “just hash maps,” and since they are “just hash
maps,” we can add, remove, or modify values of the prototype by adding,
removing, or modifying the values bound to keys of the prototype.

Attempting to think of JavaScript objects in the same manner as what most
mainstream "OO" languages semantically provide is simply wrong. "Prototypical
inheiritance" is nothing more than a shallow copy of an associative array. By
its very definition, that is _all it is_.

Now, IMHO there is nothing wrong with a hash map. There's nothing right about
it either. Those sentiments imply judgement, whereas what I have said above is
simply analyzing the nature of the subject. The fallacy in calling JavaScript
"objects" objects lies in deceiving one's self into thinking that the same
semantic guarantees OO languages provide can be done in native JavaScript. The
quicker a developer accepts that JavaScript objects are simply hash maps, the
quicker they can understand the semantic contract being proffered by the
environment _and_ be able to work with it as best as possible.

1 -
[http://www.w3schools.com/js/js_object_definition.asp](http://www.w3schools.com/js/js_object_definition.asp)

~~~
seanmcdirmid
I would argue that objects are nothing more than a uniquely identified run-
time entity. With that identity, they can easily have their own encapsulated
state (since their identity can be used as an address or key into a global
map), and can be associated with behavior that is selected dynamically.
Compare this with the dual of an object, the value, whose identity is
determined by its structure alone (e.g. 1 and 1 are the same values), and so
does not allow for state, nor does it allow for dynamic behavior selection
without first turning them into objects (aka boxing). The implications of
object-ness lead to certain styles of computation (noun-based) just as they do
for values (expression oriented and functional).

Objects existed in PL before the more limited kind in Java or even C++, not to
mention the powerful but very Java-unlike object systems Self and CLOS that
directly influenced JavaScript's design from the beginning.

The only fallacy, I think, is ascribing a notion of objects based on a couple
of mainstream data points. Objects are much richer than that.

~~~
AnEngineer
(Side note: it turns out I can't delete the other message. I must have
hallucinated having that ability last night.)

> I would argue that objects are nothing more than a uniquely identified run-
> time entity. With that identity, they can easily have their own encapsulated
> state (since their identity can be used as an address or key into a global
> map), and can be associated with behavior that is selected dynamically.

I largely agree and believe this is pretty consistent with the commonly
accepted definition of an object in the Comp Sci sense. There are a couple
examples which immediately come to mind (Smalltalk, Objective-C) along with
other languages (Ruby, Perl, Python) having the ability to selectively provide
equivalent behaviour.

Where I previously said "largely agree", the point where I disagree is when
you state "objects are nothing more than a uniquely identified run-time
entity." Objects also have associated with them a set of messages which are
either intrinsic to the environment's definition of what minimally constitutes
any object's behavioural contract, identified by the definition of the
object's type, or some mixture of the previous two along with a mechanism to
resolve message dispatching.

> Compare this with the dual of an object, the value, whose identity is
> determined by its structure alone (e.g. 1 and 1 are the same values), and so
> does not allow for state, nor does it allow for dynamic behavior selection
> without first turning them into objects (aka boxing).

Here, I think we disagree as not all languages treat values as being disjoint
from objects. I realize you mention boxing, which languages such as C# and
Java perform for _their_ definition of "plain old data" types, but this is not
the same as languages such as Ruby, which represents all values as objects
intrinsically.

> The only fallacy, I think, is ascribing a notion of objects based on a
> couple of mainstream data points.

The fallacy which I mentioned is in thinking that a person has the same checks
in JavaScript applied to collaborations as is expected in other OO
languages/environments. I view this as a direct consequence of JavaScript
objects being hash maps. Supporting this view is:

> A JavaScript object is an unordered collection of variables called named
> values. (source:
> [http://www.w3schools.com/js/js_object_definition.asp](http://www.w3schools.com/js/js_object_definition.asp))

~~~
seanmcdirmid
> Where I previously said "largely agree", the point where I disagree is when
> you state "objects are nothing more than a uniquely identified run-time
> entity." Objects also have associated with them a set of messages which are
> either intrinsic to the environment's definition of what minimally
> constitutes any object's behavioural contract, identified by the definition
> of the object's type, or some mixture of the previous two along with a
> mechanism to resolve message dispatching.

Good well-developed object abstractions have that feature, but that the
intrinsic "objectness" that leads to such a feature being desirable does not.
Plenty of us remember working with proto-objects that did not have these
features, but the nature of our objects drove us to re-discover this feature
on our own (e.g. by rolling your own v-tables for a pointer to a struct in
C!).

> Here, I think we disagree as not all languages treat values as being
> disjoint from objects. I realize you mention boxing, which languages such as
> C# and Java perform for _their_ definition of "plain old data" types, but
> this is not the same as languages such as Ruby, which represents all values
> as objects intrinsically.

Again, I'm going for a definition of objectness. That Ruby treats values as
objects isn't necessarily a good thing, and programmers will definitely want
to often treat these as values anyways even if the language is resistant to
that; e.g. somehow getting 1 == 1 to evaluate as true rather than false!
Valueness is just as important as objectness, and in most programs we use both
to certain degrees (even if our languages support one over the other).

> JavaScript applied to collaborations as is expected in other OO
> languages/environments.

We can argue whether it is a good design choice compared to other OO
languages/environments, but it definitely makes them "objects."

------
julee04
for any particular reason are you returning "this" in your rename function?

~~~
pags
Probably for chaining

~~~
thomasfoster96
Definitely for chaining.

~~~
mckoss
Chaining. Definitely for chaining.

~~~
look_lookatme
Chaining. Chaining. Definitely for chaining.

~~~
the_gipsy
TypeError: Cannot read property 'reply' of null

~~~
thomasfoster96
//TODO: Make reply a method.

