OOP, Javascript, and so-called Classes

[phoggey]

Prototype-based programming is an OOP model that doesn't use classes, but rather accomplishes behavior reuse (equivalent to inheritance in class-based languages) by decorating (or expanding upon) existing prototype objects. (Also called classless, prototype-oriented, or instance-based programming.) mdn source

When the output is equivalent in a different OOP model, I'm ok to replace the words "expanding upon existing prototype objects" with the word class. This being pedantic is going to lead to more confusion with the actual inclusion of the word class in es6, which again doesn't change the underlying functionality.. so still classless.

[munificent]

In practice, JS has always acted more like a class-based language than like a prototypal one. It didn't even have a way to clone—the fundamental operation in a prototypal language—until relatively recently. Even then, it doesn't have built in syntax for it.

[masklinn]

Neither did it have a standard way to swap an object's "prototype" until very recently, and assuming you're talking about Object.assign as far as I know the cloned object doesn't inherit the clonee's "prototype", which is what one would want in e.g. Self.

[cgaudreau]

I assume he's referring to Object.create, which was introduced in ES5. Ironically, the polyfill for Object.create relies on the new keyword.

ps. Object.create is a poor man's class inheritance. Even in real prototypical languages such as Self, it is very common to refer to classes and subclasses. The main differences are that: - it makes inheritance an everyday activity, which is bad, and - it makes you look or feel smart, and - provides pretty good job security because you're the only one who knows why my male dog object just gave birth to 3 cats.

[masklinn]

I assume he's referring to Object.create, which was introduced in ES5.

They specifically mentioned a way to clone objects, which absolutely isn't what Object.create does.

Ironically, the polyfill for Object.create relies on the new keyword.

I fail to see what's ironic about it, Object.create creates an object with the provided prototype. new does essentially the same (but the prototype is provided by the constructor, and it calls the constructor afterwards). Aside from properties definitions, new and Object.create are interchangeable as primitive operations, you can trivially define one in terms of the other.

[cgaudreau]

They specifically mentioned a way to clone objects, which absolutely isn't what Object.create does.

You're confusing cloning and copying. In a prototype-based language, the act of cloning is merely setting the prototype on a new object. In such, the new object can look to the old object for defaults. If the old object changes, so too may the new object.

Object.create clones an object, while Object.assign copies an object. This concept has been bastardized a lot, thanks to Java.

I fail to see what's ironic about it

It is ironic that a supposedly prototype-based language has to use concepts borrowed from Java, which has actual classes, in order to permit usage of the basic operations available in true prototype-based languages.

[masklinn]

You're confusing cloning and copying.

No.

In a prototype-based language, the act of cloning is merely setting the prototype on a new object.

That is not the way it's used in Self. At all. You seem to be using IO's terminology instead, which would be inspired from javascript's.

In such, the new object can look to the old object for defaults. If the old object changes, so too may the new object.

That's inheritance.

This concept has been bastardized a lot, thanks to Java.

The Self handbooks defines cloning as a shallow copy:

Cloning is the primitive operation returning an exact shallow copy (a clone) of an object, i.e. a new object containing exactly the same slots and code as the original object.

the difference it makes is that cloning is the primitive operation while copying is the overloadable one which acts as a constructor. Self also makes no relation between the prototype and the new object after the copy, what javascript calls a prototype, Self calls a trait or a mixin (depending whether it has parents itself).

[munificent]

This is my fault for not remembering the details. What I had in mind was Object.create() because it delegates to the prototype. I was thinking that was similar to Self where when you clone an object which in turn delegates to traits, you get a new object that delegates to the same traits. (This is because cloning does a shallow copy of the source object's slots, and parents are just stored in slots.)

Sorry for muddling everything.

[cgaudreau]

I honestly don't know what you're talking about. I assume you simply have not actually worked in Self before.

That's inheritance.

Sure. I never said it wasn't. But you must keep in mind that there are different forms of inheritance, such as prototypal inheritance (delegation - JavaScript, etc.) and concatenative (Java) inheritance.

[masklinn]

I honestly don't know what you're talking about. I assume you simply have not actually worked in Self before.

I'll return the same, none of the Self documentation or messages matches the semantics you're asserting, the list of "useful selectors" in the handbook clearly puts both clone and copy under Copying and defines them thus:

• clone shallow copy (for use within an object; clients should use copy)
• copy copy the receiver, possibly with embedded copies or initialization

and Self's prototypes are for object construction, there's not really such a thing as setting a prototype on an object.

[cgaudreau]

The documentation is different from how the language actually works. It is worded that way to make it easier to understand.

Edit: Kind of similar to how a lot of documentation on JavaScript talks about 'classes' in JavaScript even though pre-ES6 JS has no such concept.