Develop Reference

Javascript inhertiance in anonymous functions

I have the following code I am trying to run, I get an error at the last line. From my understanding x's prototype chain looks good. What am I missing here
var Child = (function(){
function Parent(){
this.name ="parent";
this.parentHello = function(){
console.log("parent hello "+this.name);
};
}
return function(){
function Bridge(){
}
Bridge.prototype = new Parent();
this.constructor.prototype = new Bridge();
this.hello = function(){
console.log('hello');
};
};
})();
var x = new Child();
console.log(x.constructor);
console.log(x.constructor.prototype);
x.hello();
x.constructor.prototype.parentHello(); // This works
x.parentHello(); // TypeError: x.parentHello is not a function
This is modeled after an existing code, I cannot change the structure of it. I modified the original a little bit to post as question.

Update: Why the original doesn't work. You've asked in the comments to the question why it doesn't work. I'm not going to dig up the actual specifications for this for you, but the explanation is straightforward.
You do this:
this.constructor.prototype = new Bridge();
inside the constructor function. That's too late. When the JS Engine creates an object with new it looks to the constructor function you're calling, creates a new empty object, then assigns the prototype of that object from the constructor's prototype. Then it applies the function in the context of this newly created object. Inside there, you reassign the prototype of the constructor, but it's too late.
It's easy to see that this is the issue by just doing this:
var x = new Child();
x.parentHello(); // throws an exception
var y = new Child(); // gets the updated prototype
y.parentHello(); // works as expected
But the big question is why you would want to reassign the prototype from within the constructor. It is an extremely confusing notion, even if it were to work properly.
We now return you to your originally scheduled answer.
The reason this doesn't work is that you're confusing levels, and trying to do something inside a constructor function that really should be done outside of it. Below is what I think of as the minimal modification of your code to make it work. It is not how I would suggest actually writing this, but it's a starting place for discussion:
var Child = (function(){
function Parent(){
this.name ="parent";
this.parentHello = function(){
console.log("parent hello "+this.name);
};
}
function Child() {
this.hello = function(){
console.log('hello');
};
}
function Bridge(){}
Bridge.prototype = new Parent();
Child.prototype = new Bridge();
Child.prototype.constructor = Parent;
return Child;
})();
var x = new Child();
x.hello(); //=> logs "hello"
x.parentHello(); //=> logs "parent hello parent"
Now that last block really should become an inherit function or some such:
var inherit = function(Parent, Child) {
function Bridge(){}
Bridge.prototype = new Parent();
Child.prototype = new Bridge();
Child.prototype.constructor = Parent;
return Child;
}
var Child = (function(){
function Parent(){
this.name ="parent";
this.parentHello = function(){
console.log("parent hello "+this.name);
};
}
function Child() {
this.hello = function(){
console.log('hello');
};
}
return inherit(Parent, Child);
})();
Often these days, these things are handled in one of two different ways, though. This version is pretty old-school. Instead now, if you're using es6, there is a class syntax that does pretty much the equivalent of this. And if not, techniques using Object.create are very common.

I'm going to attempt to both explain what was wrong with your code and show a better way to achieve the same inheritance you have now.
Analysis of your code:
Child is a constructor function.
In a private scope of that function is the Parent() constructor
Calling the Child function with new attepts to return a new object that initializes the Bridge constructor and prototype and then attempts to set the constructor of the current object's prototype to new Bridge().
I'm guessing here since you don't explicitly describe what you're trying to accomplish, but it looks like maybe you're trying to create two levels of inheritance where Parent is the base, then Bridge derives from Parent, then Child derives from Bridge.
But, you can't be setting the prototype for Child in the constructor of Child. That's too late to be setting it because the first Child object has already been created.
So, when you do x = new Child();, x will just be a Child object without inheriting from Bridge. Thus, there is no .parentHello() method on it.
When you create new objects with inheritance, you also need to call the inherited constructors so they can properly initialize their instances.
Fixing the code:
Since the inheritance structure here is fixed and completely known ahead of time, there is no reason to try to do this dynamically. It should be assigned once at the time the Child IIFE runs, not inside the Child constructor. This will both fix timing issues and make the code run properly.
Further, it's 2016, so we should be using Object.create() to create prototypes, not new.
And, objects needs to call the constructors of the things they inherit from.
Here's what I would suggest (you can run this snippet and look in the debug console):
var Child = (function(){
// define base class
function Parent(){
this.name ="parent";
this.parentHello = function(){
console.log("parent hello "+this.name);
};
}
Parent.prototype.constructor = Parent;
// define Bridge which inherits from Parent
function Bridge() {
// call parent constructor
Parent.call(this);
}
Bridge.prototype = Object.create(Parent.prototype);
Bridge.prototype.bridgeHello = function() {
console.log("bridge hello");
}
Bridge.prototype.constructor = Bridge;
function Child() {
// call parent constructor
Bridge.call(this);
this.hello = function(){
console.log('hello');
};
}
Child.prototype = Object.create(Bridge.prototype);
Child.prototype.constructor = Child;
return Child;
})();
var x = new Child();
console.log(x);
console.log(x.constructor);
x.hello();
x.bridgeHello();
x.parentHello();
And, here's a similar implementation using the more modern ES6 class syntax (you can run this snippet in a browser that supports ES6 classes such as Chrome, Firefox or Edge):
"use strict";
var Child = (function(){
// base class
class Parent {
constructor() {
this.name = "parent";
}
parentHello() {
console.log("parent hello "+this.name);
}
}
// define Bridge which inherits from Parent
class Bridge extends Parent {
constructor() {
super();
this.name = "bridge";
}
bridgeHello() {
console.log("bridge hello");
}
}
class Child extends Bridge {
constructor() {
super();
this.name = "child";
}
hello() {
console.log('hello');
}
}
return Child;
})();
var x = new Child();
console.log(x);
console.log(x.constructor);
x.hello();
x.bridgeHello();
x.parentHello();

JavaScript - how to use "self" from current JS Class

I tried to create this syntax for JavaScript:
var user = new Class({
name: 'No name',
sayHello: function () {
console.log(self.name);
}
});
user.sayHello(); // will print "undefined" because "self" isn't visible
And I created this implementation of Class:
function Class (_properties) {
var self = this;
// copy all properties and methods to this class
for (var _property_name in _properties) {
self[_property_name] = _properties[_property_name];
}
}
But the problem is in self that I wish to use in each class. The self.name will be undefined because self is a [Window object].
Question: how to modify my code to use self inside all functions in class instances? The self is needed to not drop context if the function will be called from external context.
Expected result (I mean that code above should be executed as code below):
function Class (_properties) {
var self = this;
// properties
self.name = 'No name';
// methods
self.sayHello = function sayHello () {
console.log(self.name);
};
}
var user = new Class();
user.sayHello();
The goal of my experiment is to use self that always is reference to current object. Because sometimes when we use calls like this $.get('...', function () { console.log(this); }) - this is set to function local scope. But I wish to use self (magic property) that always be a reference to object of current class (scope of current class).

So I finally figured out that you are talking about the self variable in the sayHello method that is giving you problems.
You need to google JavaScript scope this tutorial - it's not the most intuitive concept, but once you get it, everything will make sense.
In the mean time, it's worth pointing out that self is not a reserved word in JavaScript and doesn't do anything special, but this is.
So what you want, is something like this:
function Class (_properties) {
// copy all properties and methods to this class
for (var _property_name in _properties) {
this[_property_name] = _properties[_property_name];
}
}
var User = new Class({
name: 'No name',
sayHello: function () {
console.log(this.name);
}
});
var user1 = new User();
var user2 = new User();
The keyword new in front of the Class() function causes it to be executed as a constructor function meaning that, inside of the constructor function this will reference it's own scope.
Also, because the property sayHello is a function to be executed inside the scope that you created, you can use this.name - as this will refer to the scope that you created when you instantiated a new Class.
And just because this scope thing is no doubt confusing (don't worry, it probably will be for a while) - if you haven't created a scope (by using a constructor or object literal) you're working inside of the global scope which, in the case of the browser, is the Window object.

That's because you never created an object:
var options = {
name: 'No name',
sayHello: function () {
console.log(self.name);
}
}
var user1 = new Class(options);
var user2 = new Class(options);
"this" refers to the object owner of the current function. In this case would be windows object. At least you construct an object from the function Class.
If you want to avoid someone overwrite a property of Class.prototype is necessary to use hasOwnProperty in your for in

Method Inheritance in JavaScript

JavaScript uses a Prototype system, which is fundamentally different than a Class system. This is my first serious encounter with the language. I had fooled around with it previously, but this is the first time I built a system with proper OO, inheritance, polymorphism, etc.
From what I read there seems to be a few common methods to do member function inheritance in Javascript. Assuming you have a parent foo as following
foo = function(){ this.one = 1; }
foo.prototype.func1 = function(){return this.one;}
The MDN Introduction to JavaScript Inheritance suggests the naive approach of invoking the parent's method in the context of the child, as shown below.
bar = function(){ foo.call(this); }
bar.prototype = Object.create(foo.prototype);
bar.prototype.func1 = function(){ return this.one + foo.prototype.func1();}
This has the advantage of being simple to understand, but can become cumbersome as pointed out in this Salsify Blog post. The blog post outlines an alternate method where a super property is defined in the child prototype, and the name of each member function is attached as a property to the method. This method, however, relies on the caller property of a method, which the article points out will soon be deprecated. Rather than duplicate the entire post, I believe a summary of the important points are these
Object.defineProperty(bar.prototype, "super", {
get: function get() {
...
// methodName is set as a property on each method in an omitted code segment
methodName = get.caller.methodName;
...
Object.getPrototypeOf(this.prototype)[methodName]
}
}
Which is to say that you find the method with the same name in your prototype's prototype. I was wondering if this can be done in a simpler manner, without having to attach the method name as a parameter and without the Function.caller.
foo.prototype.super = function(method) {
superMethod = Object.getPrototypeOf(this.constructor.prototype)[method];
return superMethod.call(this, Array.prototype.slice.call(arguments, 1));
}
bar.prototype.func1 = function(){ return this.one + super('func1'); }
I'm making a number of assumptions in the above, I'd like to verify some assumptions.
new bar().constructor.prototype === Object.getPrototypeOf(new bar())
If the above is always true, is one preferable over the other?
The Parent's member function will always live in the child's prototype's prototype (assuming that neither of the prototypes were mutated after object creation)
That Object.getPrototypeOf() is not the "language support for accessing super methods" that the blog refers to as being added in ES6
If Object.getPrototypeOf() isn't that language support, what is?
After seeing the error of using this, which does not change throughout the execution and always refers to the instance of the subclass, I've revisited and am thinking I need something like this
Grandfather = function(){};
Grandfather.prototype.function1 = function(){console.log("I am the Grandfather");};
Father = function(){Grandfather.apply(this);};
Father.prototype = Object.create(Grandfather.prototype);
Father.prototype.function1 = function f(){ f.super(); console.log("I am the Father");};
Father.prototype.function1.super = Grandfather.prototype.function1;
Child = function(){Father.apply(this);}
Child.prototype = Object.create(Father.prototype);
Child.prototype.function1 = function f(){ f.super(); console.log("I am the Child");};
Child.prototype.function1.super = Father.prototype.function1;
c = new Child();
c.function1();
// I am the Grandfather
// I am the Father
// I am the Child
And so the question becomes, how to set the super property on to each function in some automatic way?
One such way to do this is shown below, it has the benefit that functions added to the prototype after objects are instantiated still receive the benefit of being able to call superFunc, whereas an approach that sets a super property at class extension time would not set such a property if functions are added to the prototype later.
The downsides of this approach are that it only works in single threaded environment and that it requires functionality inherited from a common base class. It is not threadsafe since some state is held in a what is effectively a static variable of the function. This is fine for my purposes since browsers still have single threaded JavaScript. The requirement that all classes inherit from some base class containing this method isn't a huge blocker (especially if you do a "bad thing" and insert this into Object's prototype).
Grandfather.prototype.superFunc = function f(funcName){
currentPrototype = Object.getPrototypeOf(f.startingPrototype || Object.getPrototypeOf(this));
f.startingPrototype = currentPrototype;
return currentPrototype[funcName]();
}
Child.prototype.function2 = function(){this.superFunc('function2'); console.log("Still in the Child");};
Father.prototype.function2 = function(){this.superFunc('function2'); console.log("Still in the Father");};
GrandFather.prototype.function2 = function(){console.log("Still in the Grandfather");};
c = new Child();
c.function2();
// Still in the Grandfather
// Still in the Father
// Still in the Child

Question 1
new Bar().constructor.prototype should equal Object.getPrototypeOf(new Bar()), provided you haven't overrided Bar.prototype.constructor or Bar.prototype, or return a different object in the Bar constructor. Here's an example:
function Bar() {}
var foo = new Bar();
foo.constructor.prototype === Object.getPrototypeOf(foo); // true
function Bar2() {}
var foo2 = new Bar2();
Bar2.prototype = {};
foo2.constructor.prototype === Object.getPrototypeOf(foo2); // false
function Bar3() {}
var foo3 = new Bar3();
Bar3.prototype.constructor = function NotBar3() {};
foo3.constructor.prototype === Object.getPrototypeOf(foo3); // false
Question 2
If you're looking to get the actual prototype of an object, use Object.getPrototypeOf, as that's unaffected by any of the changes shown above.
Question 3
No, you will not be able to access Foo from new Bar(). In your example, new Bar() would not inherit from Foo.prototype and as a result, there's no way to access Foo unless you make it inherit from Foo.prototype or assign Foo to a property of new Bar() or Bar.prototype.
Question 4/5
No, that's not what they're referring to. ES6 will introduce a separate class contruct, where super takes on a special meaning (similar to how super works in other languages with classes). Here's an example of how classes work in ES6:
class Foo {
constructor() {
this.one = 1;
}
func1() {
return this.one;
}
}
class Bar extends Foo {
func1() {
return this.one + super();
}
}

When you use super in the way you do it'll break when inheritance is more than 2 levels.
Assuming you'd use it the following way:
//changed super to this.super since super is not shown to exist in global scope
bar.prototype.func1(){ return this.one + this.super('func1'); }
See the following example:
function GrandFather(){
this.i = 0;
};
GrandFather.prototype.test = function(){
console.log('test in GrandFather');
};
function Father(){
GrandFather.call(this);
};
Father.prototype = Object.create(GrandFather.prototype);
Father.prototype.constructor = Father;
Father.prototype.super = GrandFather.prototype;
Father.prototype.test = function(){
console.log('test in Father');
//prevent too many recursions
this.i++;
if(this.i>5){
return;
}
this.super.test.call(this);//because test in child was called
// with Child instance as invoking object this will be Child
// and this.super will be Father.prototype
};
function Child(){
Father.call(this);
}
Child.prototype = Object.create(Father.prototype);
Child.prototype.constructor = Child;
Child.prototype.super = Father.prototype;
Child.prototype.test = function(){
console.log('test in Child');
this.super.test.call(this);//because invoking object is Child
//this.super in Father is Child
};
var c = new Child();
c.test();
It's also common practice to start a constructor function with a capital so it's better to use Foo and Bar for constructor function names.
If you want to go through all the trouble of simulating super in JavaScript then the following way would be slightly more robust: http://ejohn.org/blog/simple-javascript-inheritance/

Why refer to static variables (function properties) outside the function definition?

I was looking at Static variables in JavaScript and I noticed something I'd seen before, that the function is defined and after the function definition the function prototype is updated:
function MyClass () { // constructor function
//function definition here
}
//now add a (static?) method *outside* the function definition
MyClass.prototype.publicMethod = function () {
alert(this.publicVariable);
};
//add a static property *outside* the function definition
MyClass.staticProperty = "baz";
Here's my question - why not define them inside the function defintion, like this:
function MyFunc(){
MyFunc.staticVar = 1;
//static method showing static var
MyFunc.showVarStatic = function(){
alert(MyFunc.staticVar);
}
//instance method referring to static var
this.showVarInstance = function(){
alert(MyFunc.staticVar);
}
//instance method - doesn't change static var
this.inc1 = function(){
this.staticVar += 1;//no such property
}
//static method, changes var
this.inc2 = function(){
MyFunc.staticVar += 1;//increments static property
}
}
This seems to behave as expected in IE8, FF, and Chrome. Is this just a personal preference / style thing? I like it, because my whole function is contained in those curly brackets.
[EDIT: after doing more reading and experimenting, I have better understand of how javascript functions are constructors, and how they differ from, for example, C# classes - here's some code I used to demonstrate this]
//this is deceiving, notSoStaticVar won't exist until MyFunc1 has been run
//and then it will be reset whenever MyFunc1 (a constructor) is run
function MyFunc1(){
MyFunc1.notSoStaticVar = "I belong to MyFunc1";
this.instanceVar = "I belong to instances of MyFunc1";
}
//this code will be run inline one time,
//so the static property of MyFunc2 will exist
//(I like how all the functionality is in one code block, but it's kind of messy)
MyFunc2 = (function(){
var temp = function(){
this.instanceVar = "I belong to an instance of MyFunc2";
}
temp.staticVar = "I belong to MyFunc2";
return temp;
})();
//this seems to be equivalent to MyFunc2, but the code is cleaner
MyFunc3 = function(){
}
MyFunc3.prototype.instanceVar = "I belong to an instance of MyFunc3";
MyFunc3.staticVar = "I belong to MyFunc3";
//tests
console.log(MyFunc1.notSoStaticVar);//undefined!
var a = new MyFunc1();
console.log(MyFunc1.notSoStaticVar);//"I belong to MyFunc1"
console.log(a.instanceVar);//"I belong to instances of MyFunc1"
MyFunc1.notSoStaticVar = "I will be changed when another instance of MyFunc1 is created";
console.log(MyFunc1.notSoStaticVar);//"I will be changed when another instance of MyFunc1 is created"
var b = new MyFunc1();
console.log(MyFunc1.notSoStaticVar);//"I belong to MyFunc1" - was reset by constructor!
//now test MyFunc2
console.log(MyFunc2.staticVar);//"I belong to MyFunc2"
MyFunc2.staticVar = "I am not affected by the construction of new MyFunc2 objects";
var c = new MyFunc2();
console.log(c.instanceVar);//"I belong to an instance of MyFunc2"
console.log(MyFunc2.staticVar);//"I am not affected by the construction of new MyFunc2 objects"
//now test MyFunc3
console.log(MyFunc3.staticVar);//"I belong to MyFunc3"
MyFunc3.staticVar = "I am not affected by the construction of new MyFunc3 objects";
var d = new MyFunc3();
console.log(d.instanceVar);//"I belong to an instance of MyFunc3"
console.log(MyFunc3.staticVar);//"I am not affected by the construction of new MyFunc3 objects"
//interesting
console.log(c);//"temp" <-- not really intuitive!
console.log(d);//"MyFunc3" <-- makes sense

In short: performance.
Defining them inside the function will cause them to be redefined every single time you call the constructor.
While this will behave as expected, it's just overhead for no good reason.

Because that will add unique functions to every object instance. This consumes additional memory overhead that often isn't necessary.
It can be useful in some cases, like when functions should reference local variables, but if that's not the situation, they should be on the prototype.
Also, the static ones will constantly be overwritten.

Javascript: Calling private method from prototype method

I am sure that this must be a pretty common question but after scouring the internets for several hours, I have not found an answer. Here is the question:
Suppose that I have an interface called mammal. Every Mammal has to be able to sleep and eat. (In the future I may throw exceptions for the Mammal class to force children to implement the function).
function Mammal() {};
Mammal.prototype.eat = function() {};
Mammal.prototype.sleep = function() {};
Now suppose that I have a Dog class who implements the Mammal class:
function Dog() {};
Dog.prototype = new Mammal();
Dog.prototype.eat = function() {
...
};
Dog.prototype.sleep = function() {
...
};
The dog's eat function is very complicated and I would like to use a helper function. I have not been able to figure out what the best way to do this is. Here are the points of consideration:
The helper function should never be called from outside of the dog class so ideally it should be private.
The eat function does not have access to private functions (prototypes do not have access to private functions)
I could put the helper function into a privalaged function but:
This would still be a public function -> ie: everyone has the right to call it
It would not be part of the prototype so every dog would need to have its own helper function. If there were lots of dogs this seems inefficient.
I cannot make the eat function a privaliged function because in order for prototype inheritance to work it needs to be part of the prototype.
Question: How can I call a private function from a prototype function? Or more generally: When an object (child object) inherits from another object (parent object) how should children methods use helper functions and is it possible to make these private?

Define your Dog "class" in a closure. Then you can have shared priveliged functions. Just know you will have to be careful about this binding properly when you call it.
var Dog = (function() {
function Dog() {};
// Common shared private function, available only to Dog.
var privateHelper = function() { ... };
Dog.prototype = new Mammal();
Dog.prototype.eat = function() {
privateHelper()
// Or this if the helper needs to access the instance.
// privateHelper.call(this);
...
};
return Dog;
})();
A function on a prototype is still just a function. So follows the same scope and closure access rules as any another function. So if you define your entire Dog constructor and prototype and a secluded island of scope that is the self executing function, you are welcome to share as much as you like without exposing or polluting the public scope.
This is exactly how CoffeeScript classes compile down to JS.

It's not possible. If you need access to private variables/functions, you must use privileged (helper) functions.
It sometimes is possible to use helper functions in a local closure scope instead of private helper functions (in the constructor scope), which would be accessible from prototype functions. See Alex Wayne's or Raynos' answers for that.
You said:
I cannot make the eat function a privaliged function because in order for prototype inheritance to work it needs to be part of the prototype.
Why not?
MammalPrototype = {
eat: function() {},
sleep: function() {}
};
function Dog(color) {
...
this.eat = function() {
... // using private functions
MammalPrototype.eat.call(this, options) // ?
};
};
Dog.prototype = Object.create(MammalPrototype); // inherit from an object
new Mammal() is OK when Mammal really is only a empty function. See https://stackoverflow.com/a/5199135/1048572 for how this works. The shim proposed there is of course not what a native implementation does, but it is exactly what we need here. Do not create a instance just to inherit from it!
Dog.prototype.sleep = function() {
...
};
function Dalmatian() {
Dog.call(this, "black.white");
...
}
Dalmatian.prototype = Object.create(Dog.prototype); // sic
Dalmatian.prototype.xyz = function() {};
To call the super constructor on this means to receive all privileged methods, and their functionality. You will need to do this if you are using private variables and/or functions in "classes" you inherit from, otherwise all calls to inherited privileged functions will affect only the one instance you've set your prototype to.

When an object (child object) inherits from another object (parent object) how should children methods use helper functions and is it possible to make these private?
You need some layers of abstraction to achieve what you want: Live Example
Uses klass
var Mammal = klass(function (privates) {
privates.local_helper = function () {
console.log("local_helper invoked");
}
return {
constructor: function () {
console.log("mammal constructed");
privates(this).caneat = true;
},
eat: function () {
privates.local_helper();
console.log("mammal eat");
},
sleep: function () {
console.log("mammal sleep");
}
};
});
var Dog = klass(Mammal, function (privates, $super) {
return {
constructor: function () {
$super.constructor.call(this);
console.log("dog constructed");
},
eat: function () {
$super.eat.call(this);
privates.local_helper();
console.log("dog eat");
console.log(privates(this).caneat);
}
};
});
var dog = new Dog();
dog.eat();