In the section about inheritance in the MDN article Introduction to Object Oriented Javascript, I noticed they set the prototype.constructor:
// correct the constructor pointer because it points to Person
Student.prototype.constructor = Student;
Does this serve any important purpose? Is it okay to omit it?
It's not always necessary, but it does have its uses. Suppose we wanted to make a copy method on the base Person class. Like this:
// define the Person Class
function Person(name) {
this.name = name;
}
Person.prototype.copy = function() {
// return new Person(this.name); // just as bad
return new this.constructor(this.name);
};
// define the Student class
function Student(name) {
Person.call(this, name);
}
// inherit Person
Student.prototype = Object.create(Person.prototype);
Now what happens when we create a new Student and copy it?
var student1 = new Student("trinth");
console.log(student1.copy() instanceof Student); // => false
The copy is not an instance of Student. This is because (without explicit checks), we'd have no way to return a Student copy from the "base" class. We can only return a Person. However, if we had reset the constructor:
// correct the constructor pointer because it points to Person
Student.prototype.constructor = Student;
...then everything works as expected:
var student1 = new Student("trinth");
console.log(student1.copy() instanceof Student); // => true
Does this serve any important purpose?
Yes and no.
In ES5 and earlier, JavaScript itself didn't use constructor for anything. It defined that the default object on a function's prototype property would have it and that it would refer back to the function, and that was it. Nothing else in the specification referred to it at all.
That changed in ES2015 (ES6), which started using it in relation to inheritance hierarchies. For instance, Promise#then uses the constructor property of the promise you call it on (via SpeciesConstructor) when building the new promise to return. It's also involved in subtyping arrays (via ArraySpeciesCreate).
Outside of the language itself, sometimes people would use it when trying to build generic "clone" functions or just generally when they wanted to refer to what they believed would be the object's constructor function. My experience is that using it is rare, but sometimes people do use it.
Is it okay to omit it?
It's there by default, you only need to put it back when you replace the object on a function's prototype property:
Student.prototype = Object.create(Person.prototype);
If you don't do this:
Student.prototype.constructor = Student;
...then Student.prototype.constructor inherits from Person.prototype which (presumably) has constructor = Person. So it's misleading. And of course, if you're subclassing something that uses it (like Promise or Array) and not using class¹ (which handles this for you), you'll want to make sure you set it correctly. So basically: It's a good idea.
It's okay if nothing in your code (or library code you use) uses it. I've always ensured it was correctly wired up.
Of course, with ES2015 (aka ES6)'s class keyword, most of the time we would have used it, we don't have to anymore, because it's handled for us when we do
class Student extends Person {
}
¹ "...if you're subclassing something that uses it (like Promise or Array) and not using class..." — It's possible to do that, but it's a real pain (and a bit silly). You have to use Reflect.construct.
TLDR; Not super necessary, but will probably help in the long run, and it is more accurate to do so.
NOTE: Much edited as my previous answer was confusingly written and had some errors that I missed in my rush to answer. Thanks to those who pointed out some egregious errors.
Basically, it's to wire subclassing up correctly in Javascript. When we subclass, we have to do some funky things to make sure that the prototypal delegation works correctly, including overwriting a prototype object. Overwriting a prototype object includes the constructor, so we then need to fix the reference.
Let's quickly go through how 'classes' in ES5 work.
Let's say you have a constructor function and its prototype:
//Constructor Function
var Person = function(name, age) {
this.name = name;
this.age = age;
}
//Prototype Object - shared between all instances of Person
Person.prototype = {
species: 'human',
}
When you call the constructor to instantiate, say Adam:
// instantiate using the 'new' keyword
var adam = new Person('Adam', 19);
The new keyword invoked with 'Person' basically will run the Person constructor with a few additional lines of code:
function Person (name, age) {
// This additional line is automatically added by the keyword 'new'
// it sets up the relationship between the instance and the prototype object
// So that the instance will delegate to the Prototype object
this = Object.create(Person.prototype);
this.name = name;
this.age = age;
return this;
}
/* So 'adam' will be an object that looks like this:
* {
* name: 'Adam',
* age: 19
* }
*/
If we console.log(adam.species), the lookup will fail at the adam instance, and look up the prototypal chain to its .prototype, which is Person.prototype - and Person.prototype has a .species property, so the lookup will succeed at Person.prototype. It will then log 'human'.
Here, the Person.prototype.constructor will correctly point to Person.
So now the interesting part, the so-called 'subclassing'. If we want to create a Student class, that is a subclass of the Person class with some additional changes, we'll need to make sure that the Student.prototype.constructor points to Student for accuracy.
It doesn't do this by itself. When you subclass, the code looks like this:
var Student = function(name, age, school) {
// Calls the 'super' class, as every student is an instance of a Person
Person.call(this, name, age);
// This is what makes the Student instances different
this.school = school
}
var eve = new Student('Eve', 20, 'UCSF');
console.log(Student.prototype); // this will be an empty object: {}
Calling new Student() here would return an object with all of the properties we want. Here, if we check eve instanceof Person, it would return false. If we try to access eve.species, it would return undefined.
In other words, we need to wire up the delegation so that eve instanceof Person returns true and so that instances of Student delegate correctly to Student.prototype, and then Person.prototype.
BUT since we're calling it with the new keyword, remember what that invocation adds? It would call Object.create(Student.prototype), which is how we set up that delegational relationship between Student and Student.prototype. Note that right now, Student.prototype is empty. So looking up .species an instance of Student would fail as it delegates to only Student.prototype, and the .species property doesn't exist on Student.prototype.
When we do assign Student.prototype to Object.create(Person.prototype), Student.prototype itself then delegates to Person.prototype, and looking up eve.species will return human as we expect. Presumably we would want it to inherit from Student.prototype AND Person.prototype. So we need to fix all of that.
/* This sets up the prototypal delegation correctly
*so that if a lookup fails on Student.prototype, it would delegate to Person's .prototype
*This also allows us to add more things to Student.prototype
*that Person.prototype may not have
*So now a failed lookup on an instance of Student
*will first look at Student.prototype,
*and failing that, go to Person.prototype (and failing /that/, where do we think it'll go?)
*/
Student.prototype = Object.create(Person.prototype);
Now the delegation works, but we're overwriting Student.prototype with an of Person.prototype. So if we call Student.prototype.constructor, it would point to Person instead of Student. This is why we need to fix it.
// Now we fix what the .constructor property is pointing to
Student.prototype.constructor = Student
// If we check instanceof here
console.log(eve instanceof Person) // true
In ES5, our constructor property is a reference that refers to a function that we've written with the intent to be a 'constructor'. Aside from what the new keyword gives us, the constructor is otherwise a 'plain' function.
In ES6, the constructor is now built into the way we write classes - as in, it's provided as a method when we declare a class. This is simply syntactic sugar but it does accord us some conveniences like access to a super when we are extending an existing class. So we would write the above code like this:
class Person {
// constructor function here
constructor(name, age) {
this.name = name;
this.age = age;
}
// static getter instead of a static property
static get species() {
return 'human';
}
}
class Student extends Person {
constructor(name, age, school) {
// calling the superclass constructor
super(name, age);
this.school = school;
}
}
I'd disagree. It isn't necessary to set the prototype. Take that exact same code but remove the prototype.constructor line. Does anything change? No. Now, make the following changes:
Person = function () {
this.favoriteColor = 'black';
}
Student = function () {
Person.call(this);
this.favoriteColor = 'blue';
}
and at the end of the test code...
alert(student1.favoriteColor);
The color will be blue.
A change to the prototype.constructor, in my experience, doesn't do much unless you're doing very specific, very complicated things that probably aren't good practice anyway :)
Edit:
After poking around the web for a bit and doing some experimentation, it looks like people set the constructor so that it 'looks' like the thing that is being constructed with 'new'. I guess I would argue that the problem with this is that javascript is a prototype language - there is no such thing as inheritence. But most programmers come from a background of programming that pushes inheritence as 'the way'. So we come up with all sorts of things to try and make this prototypical language a 'classic' language.. such as extending 'classes'. Really, in the example they gave, a new student is a person - it isn't 'extending' from another student.. the student is all about the person, and whatever the person is the student is as well. Extend the student, and whatever you've extended is a student at heart, but is customized to fit your needs.
Crockford is a bit crazy and overzealous, but do some serious reading on some of the stuff that he's written.. it'll make you look at this stuff very differently.
This has the huge pitfall that if you wrote
Student.prototype.constructor = Student;
but then if there was a Teacher whose prototype was also Person and you wrote
Teacher.prototype.constructor = Teacher;
then the Student constructor is now Teacher!
Edit:
You can avoid this by ensuring that you had set the Student and Teacher prototypes using new instances of the Person class created using Object.create, as in the Mozilla example.
Student.prototype = Object.create(Person.prototype);
Teacher.prototype = Object.create(Person.prototype);
So far confusion is still there.
Following the original example, as you have an existing object student1 as:
var student1 = new Student("Janet", "Applied Physics");
Suppose you don't want to know how student1 is created, you just want another object like it, you can use the constructor property of student1 like:
var student2 = new student1.constructor("Mark", "Object-Oriented JavaScript");
Here it will fail to get the properties from Student if the constructor property is not set. Rather it will create a Person object.
Got a nice code example of why it is really necessary to set the prototype constructor..
function CarFactory(name){
this.name=name;
}
CarFactory.prototype.CreateNewCar = function(){
return new this.constructor("New Car "+ this.name);
}
CarFactory.prototype.toString=function(){
return 'Car Factory ' + this.name;
}
AudiFactory.prototype = new CarFactory(); // Here's where the inheritance occurs
AudiFactory.prototype.constructor=AudiFactory; // Otherwise instances of Audi would have a constructor of Car
function AudiFactory(name){
this.name=name;
}
AudiFactory.prototype.toString=function(){
return 'Audi Factory ' + this.name;
}
var myAudiFactory = new AudiFactory('');
alert('Hay your new ' + myAudiFactory + ' is ready.. Start Producing new audi cars !!! ');
var newCar = myAudiFactory.CreateNewCar(); // calls a method inherited from CarFactory
alert(newCar);
/*
Without resetting prototype constructor back to instance, new cars will not come from New Audi factory, Instead it will come from car factory ( base class ).. Dont we want our new car from Audi factory ????
*/
No need for sugared function 'classes' or using 'New' these days. Use object literals.
The Object prototype is already a 'class'. When you define an object literal, it is already an instance of the prototype Object. These can also act as another object's prototype, etc.
const Person = {
name: '[Person.name]',
greeting: function() {
console.log( `My name is ${ this.name || '[Name not assigned]' }` );
}
};
// Person.greeting = function() {...} // or define outside the obj if you must
// Object.create version
const john = Object.create( Person );
john.name = 'John';
console.log( john.name ); // John
john.greeting(); // My name is John
// Define new greeting method
john.greeting = function() {
console.log( `Hi, my name is ${ this.name }` )
};
john.greeting(); // Hi, my name is John
// Object.assign version
const jane = Object.assign( Person, { name: 'Jane' } );
console.log( jane.name ); // Jane
// Original greeting
jane.greeting(); // My name is Jane
// Original Person obj is unaffected
console.log( Person.name ); // [Person.name]
console.log( Person.greeting() ); // My name is [Person.name]
This is worth a read:
Class-based object-oriented languages, such as Java and C++, are
founded on the concept of two distinct entities: classes and
instances.
...
A prototype-based language, such as JavaScript, does not make this
distinction: it simply has objects. A prototype-based language has the
notion of a prototypical object, an object used as a template from
which to get the initial properties for a new object. Any object can
specify its own properties, either when you create it or at run time.
In addition, any object can be associated as the prototype for another
object, allowing the second object to share the first object's
properties
It is necessary when you need an alternative to toString without monkeypatching:
//Local
foo = [];
foo.toUpperCase = String(foo).toUpperCase;
foo.push("a");
foo.toUpperCase();
//Global
foo = [];
window.toUpperCase = function (obj) {return String(obj).toUpperCase();}
foo.push("a");
toUpperCase(foo);
//Prototype
foo = [];
Array.prototype.toUpperCase = String.prototype.toUpperCase;
foo.push("a");
foo.toUpperCase();
//toString alternative via Prototype constructor
foo = [];
Array.prototype.constructor = String.prototype.toUpperCase;
foo.push("a,b");
foo.constructor();
//toString override
var foo = [];
foo.push("a");
var bar = String(foo);
foo.toString = function() { return bar.toUpperCase(); }
foo.toString();
//Object prototype as a function
Math.prototype = function(char){return Math.prototype[char]};
Math.prototype.constructor = function()
{
var i = 0, unicode = {}, zero_padding = "0000", max = 9999;
while (i < max)
{
Math.prototype[String.fromCharCode(parseInt(i, 16))] = ("u" + zero_padding + i).substr(-4);
i = i + 1;
}
}
Math.prototype.constructor();
console.log(Math.prototype("a") );
console.log(Math.prototype["a"] );
console.log(Math.prototype("a") === Math.prototype["a"]);
EDIT, I was actually wrong. Commenting the line out doesn't change it's behavior at all. (I tested it)
Yes, it is necessary. When you do
Student.prototype = new Person();
Student.prototype.constructor becomes Person. Therefore, calling Student() would return an object created by Person. If you then do
Student.prototype.constructor = Student;
Student.prototype.constructor is reset back to Student. Now when you call Student() it executes Student, which calls the parent constructor Parent(), it returns the correctly inherited object. If you didn't reset Student.prototype.constructor before calling it you would get an object that would not have any of the properties set in Student().
Given simple constructor function:
function Person(){
this.name = 'test';
}
console.log(Person.prototype.constructor) // function Person(){...}
Person.prototype = { //constructor in this case is Object
sayName: function(){
return this.name;
}
}
var person = new Person();
console.log(person instanceof Person); //true
console.log(person.sayName()); //test
console.log(Person.prototype.constructor) // function Object(){...}
By default (from the specification https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/constructor), all prototypes automatically get a property called constructor that points back to the function on which it is a property.
Depending on the constructor, other properties and methods might be added to the prototype which is not a very common practice but still it is allowed for extensions.
So simply answering: we need make sure that the value in prototype.constructor is correctly set as it is supposed by the specification to be.
Do we have to always set correctly this value? It helps with debugging and makes internal structure consistent against specification. We should definitely when our API is being used by the thirdparties, but not really when the code is finally executed in the runtime.
Here's one example from MDN which I found very helpful to understand its uses.
In JavaScript, we have async functions which returns AsyncFunction object. AsyncFunction is not a global object but one may retrieve it by using constructor property and utilize it.
function resolveAfter2Seconds(x) {
return new Promise(resolve => {
setTimeout(() => {
resolve(x);
}, 2000);
});
}
// AsyncFunction constructor
var AsyncFunction = Object.getPrototypeOf(async function(){}).constructor
var a = new AsyncFunction('a',
'b',
'return await resolveAfter2Seconds(a) + await resolveAfter2Seconds(b);');
a(10, 20).then(v => {
console.log(v); // prints 30 after 4 seconds
});
It is necessary. Any class in class inheritance must has its own constructor, so as in prototype inheritance.It is also convenient for object construction. But the question is unnecessary and what is necessary is understanding in JavaScript world effect of calling function as constructor and rule of resolving object property.
Effect of executing function as constructor with expression new <function name>( [ parameters] )
a object whose type name is the function name is created
inner properties in the function attaches to the created object
property prototype of the function attaches automatically to the created object as prototype
Rule of resolving property of object
The property will not only be sought on the object but on the prototype of the object, the prototype of the prototype, and so on until either a property with a matching name is found or the end of the prototype chain is reached.
Basing on these underlying mechanisms, statement <constructor name>.prototype.constructor = <constructor name> equals in term of effect to attach constructor in constructor body with expression this.constructor = <constructor name>. The constructor will be resolved on the object if second utterance while on object's prototype if first utterance.
It is not necessary. It is just one of the many things traditional, OOP champions do to try to turn JavaScript's prototypical inheritance into classical inheritance. The only thing that the following
Student.prototype.constructor = Student;
does, is that you now have a reference of the current "constructor".
In Wayne's answer, that has been marked as correct, you could the exact same thing that the following code does
Person.prototype.copy = function() {
// return new Person(this.name); // just as bad
return new this.constructor(this.name);
};
with the code below (just replace this.constructor with Person)
Person.prototype.copy = function() {
// return new Person(this.name); // just as bad
return new Person(this.name);
};
Thank God that with ES6 classical inheritance purists can use language's native operators like class, extends and super and we don't have to see like prototype.constructor corrections and parent refereces.
This is my first question on stackoverflow and I am complete beginner in javascript. I was reading about object oriented programming in javascript using this article ,http://javascriptissexy.com/oop-in-javascript-what-you-need-to-know>. In the section named "OOP in javascript", it describes two ways of creating and object:
var myObj = {name:"Richard", profession:"Developer"};
I know you can access the propertise of this object by
myObj.name // "Richard"
The Second way the article describes of creating an object is
function People (name, profession) {}
var richard = new People (“Richard”, “Developer”)
How do I access the name property of this object ??
Also I haven't read the rest of the article past this topic. I am stuck until this concept is cleared.
In the constructor function you need to do something like this:
function People (name, profession) {
this.name = name;
this.profession = profession;
}
Then you can access the properties like you did with the first method.
richard.name // 'Richard'
Remember that the constructor is nothing but an ordinary function. Calling it with new just means that it gets an empty object as its receiver, i.e the this value inside the function.
the second way is called the constructor pattern.
for which you have to modify your code like below
function People (name, profession) {
this.name = name;
this.profession = profession;
}
in the above code "this" refers to the individual instances that you would create with the "new" operator.
now we create the object.
var richard = new People (“Richard”, “Developer”);
and then access the properties like
richard.name;
richard.profession;
explained well here with great information on other ways to create objects.
I have this javasctipt class
function employee(name, jobtitle, born)
{
this.name = name;
this.jobtitle = jobtitle;
this.born = born;
}
var fred = new employee("Fred Flintstone", "Caveman", 1970);
employee.prototype.salary = null;
fred.salary = 20000;
fred.notprototype = 1239;
console.log(fred);
now as you can see I added salary property using prototype but then I just added a property by using fred.notprototype = 1239; without the use of prototype.
when I did the console.log on object fred I see notprototype there. So Is it wrong not to add the prototype? If it is then what difference is it making?
Let's say, after all that code you add this:
var john = new employee("John Carson", "Philantropist", 2015);
console.log(john);
It will show that john has a salary attribute (of value null). You didn't set that yourself, it comes from the prototype chain.
By adding to a prototype of X, you change all objects that are created by new X().
Another example:
function School(name)
{
this.name = name;
}
School.prototype.getName = function() {
return this.name;
}
var school_one = new School('one');
console.log(school_one.getName()); // prints "one"
In this example, a method getName was added to the prototype. Upon creation of the school_one object it inherits from School.prototype all that you have added to it (in this case just that one method).
This can be used to declare the object's interface (methods you use to access it) or default values separate from the constructor.
To get a deeper understanding of JavaScript and its unique features, I highly recommend checking out a few videos from Douglas Crockford; he's a great speaker and highly knowledgeable, love listening to him :)
Properties on the prototype do two things:
for "plain" variables, they can provide a default value, which will be hidden the first time you write a property with the same name to an object
for member functions, they reduce the overhead of every instance of the object containing its own copy of that function.
I'm probably missing something really basic on javascript knowledge, but why doesn't this work?
var person = {
name:"",
age:0,
set : function(name,age){
this.name = name;
this.age = age;
}
}
var me = new person; // ERROR: Object doesn't support this action!
me.set('Victor',12);
me.name //Victor
But this does:
var person = function(){
this.name="";
this.age=0;
this.set = function(name,age){
this.name=name;
this.age=age;
}
}
var me = new person(); //WORKS!
me.set('Victor',12);
me.name; //Victor
Your first example was an object literal:
var person = {
name: "Bob",
//etc
};
You've created a single object called person, and that's that. The concept of creating new persons has no meaning.
If you want to create something that can be used to create more objects at will, you'd use a function, like your second example.
Note though that functions intended to be used as a constructor start with a capital letter by convention. Also note that when you set a function inside of your constructor using
this.functionName = function() .....
this creates a privileged function, since it has access to both public, and private members. If this set function only needs access to public properties, it would usually be added to the function's prototype. Here's how the whole thing might look
function Person() {
this.name = "";
this.age = 0;
};
Person.prototype.set = function(name,age) {
this.name = name;
this.age = age;
}
And here's what a privileged method might look like
function Person() {
var localData = "Hello";
this.showPrivateData = function() {
alert(localData);
};
this.name="";
this.age=0;
};
localData is local to the Person function, and cannot be accessed as a property on instances of Person; however, the showPrivateData function, and any other privileged functions you might add, would form a closure over it, and have access to it.
Finally, note that constructor functions can take parameters:
function Person(name, age) {
this.name= name;
this.age= age;
};
You answer your own question. A constructor (the thing that goes next to new) must be a function in JavaScript.
JavaScript has no classes (although you can simulate them), this is why. And new works only on functions (in this case it creates special variable this inside function, which is being returned implicitly after function call).
So, when using this:
var person = {
name:"",
age:0,
set : function(name,age){
this.name = name;
this.age = age;
}
};
you already create an object (which has a function as one of its properties).
But when you use this:
var person = function(){
this.name="";
this.age=0;
this.set = function(name,age){
this.name=name;
this.age=age;
}
};
you only create function, that returns this with all assigned properties when the function is called with new.
What documentation says
As documentation of new operator on Mozilla Developer Network says:
The new operator creates an instance of a user-defined object type or of one of the built-in object types that has a constructor function.
...
Creating a user-defined object requires two steps:
Define the object type by writing a function.
Create an instance of the object with new.
and you basically make both steps in the second case.
The first version uses an object literal to create a single object instance which is assigned to person. This cannot be used like a constructor with new to create other objects from person.
The second version uses a function, which can be called as a constructor to create new objects with new person().
That's just the way new works in JavaScript. Essentially if you want to be able to create multiple instances from a template (similar to how classes work in other languages) then use the new FunctionName() syntax. If you only need to create a single instance of a particular object you can use the first syntax.
Note that in the first version you can say:
person.set('Victor',12);
alert(person.name); // 'Victor'
Note also that if you are creating a function that is intended for use as a constructor the convention is to use uppercase for the first letter of its name (or the first letter of each word in the name).
Can you call a function as an object? For example:
function Tip(txt){
this.content = txt;
this.shown = false;
}
And:
var tip = new Tip(elem.attr('title'));
My questions:
Can you call new for a function, as for an object?
The use of "this" is made possible, because we use that function as an object?
You are looking for the constructor concept.
All functions in JavaScript are objects and can be used to create objects:
function make_person(firstname, lastname, age) {
person = {};
person.firstname = firstname;
person.lastname = lastname;
person.age = age;
return person;
}
make_person("Joe", "Smith", 23);
// {firstname: "Joe", lastname: "Smith", age: 23}
However, in order to create new objects of a particular type (that is to say, that inherit a prototype, have a constructor, etc), a function can reference this and if it is called with the new operator then it will return an object with all of the attributes that are defined on this in the function - this in such cases references the new object we are creating.
function make_person_object(firstname, lastname, age) {
this.firstname = firstname;
this.lastname = lastname;
this.age = age;
// Note, we did not include a return statement
}
The key difference to note between make_person and make_person_object is that calling new make_person() (as opposed to simply make_person()) will not do anything different ... both will produce the same object. Calling make_person_object() without the new operator however, will define your this attributes on the current this object (generally window if you are operating in the browser.)
Thus:
var Joe = make_person_object("Joe", "Smith", 23);
console.log(Joe); // undefined
console.log(window.firstname) // "Joe" (oops)
var John = new make_person_object("John", "Smith", 45);
console.log(John); // {firstname: "John", lastname: "Smith", age: 45}
Also, as #RobG points out, this way of doing things creates a reference to the prototype property of make_person_object on each "Person" we create. This enables us to add methods and attributes to persons after the fact:
// Assuming all that came before
make_person_object.prototype.full_name = "N/A";
make_person_object.prototype.greet = function(){
console.log("Hello! I'm", this.full_name, "Call me", this.firstname);
};
John.full_name // "N/A"
John.full_name = "John Smith";
make_person_object.full_name // Still "N/A"
John.greet(); // "Hello! I'm John Smith Call me John"
Convention has it that constructor functions like make_person_object are capitalized, singularized and "nouned" (for lack of a better term) -- thus we would have a Person constructor, rather than a make_person_object which might be mistaken for an ordinary function.
See also:
The new operator
bobince's great introduction to subclassing in JavaScript (both with and without prototype inheritance.)
Every function has a reference to this. if you call Tip(), this will refer to the global object. If you call new Tip(), a new object with a reference to Tip.prototype is created and this will refer to that new object.
You can't use new on objects, for instance new {} throws TypeError: object is not a function. If you are refering to new Object() then that works since Object is a function.
Yes. In JavaScript, technically everything is an object. When you use new, it creates an instance of the Tip object and then calls the Tip function as if it were a constructor.
If you want to add functions to the Tip object, you should add them to Tip's prototype like so:
Tip.prototype.getContent = function() {
return this.content;
};
If you have that, and then you do:
var tip = new Tip("this is my content.");
alert(tip.getContent());
It'll show a message saying "this is my content."
You can only use new, however, if the object has a functional implementation. So this won't work:
var Tip = { content: txt, show: false };
var tipObj = new Tip();
I have struggled to understand these concepts(functions as objects, prototype objects, __proto__ property, constructor property) for almost 8 years(2008-2016). First I started David Flanagan "JavaScript Definitive Guide 5/6th ed" for 4-5 years after multiple readings of Chapters 6,8,9; it did not make any sense to me but after struggling on Internet I some what able to manage functions(typical C++ function with properties) as objects; because object can also have methods. And luckily in 7th year 2015, I started Wrox Nicholas C. Zakas "Professional JavaScript for Web Developers 3rd ed" Chapter 6,7; and it was really very helpful to understand above four concepts. Traditionally in C/C++/C# functions are thought of as to modify an object; or in other words they are made for the "doing something" where as Objects are made for maintaining state of global running context with methods to change its own object state. So if functions can be first class objects then why objects can not be like functions ?
The main key question here should be WHY ? Why not single conceptual entity
like "associative-function" or "chained-arguments" ? And here is my understanding:
Browser exe is a single threaded application and this exe controls calling JS interpreter with predefined scope chain(some what similar to a string of commands with arguments); now at runtime the JS engine(not interpreter) loads the code in hoisting fashion(since there is no main method so uplifting the well defined keyworded codes and its call). In this hoisted code if functions are not treated as objects then they have to be maintained on separate call context(out of scope chain) which is easily possible in c/c++/c#(bcoz of multi thread and unlimited memory) but not in JS. Hence "to-do smth on chained object" makes a java script function as first class object. In fact JS objects also do the same thing; the only difference is "calling an object" is not there in objects where as "calling a function" is chained context which make sense. Functions can also be thought of as "bunch of variables with assembly language instructions with address link(chain)". The linking part is another side of story as top->bottom linking(prototype object) vs bottom->top linking(__proto__ property) vs object blue print->object instances(constructor property). Few months back I found the following image as helpful for understanding linking.
http://judis.me/wordpress/wp-content/uploads/2015/08/JavaScriptDiagram.png "JS Object model"
for #1 : There is an object called Function (capital F)
var f = new Function("x", "y", "return x*y;");
for #2 : the "this" is different depending on innvocation pattern (as termed by Douglas Crockford). Crockford said there are 4 patterns ( method pattern , function pattern , constructor pattern , and "apply" pattern )
The function is acting as a constructor on a class. Alternatively, you could do:
function Tip(txt) {
return {
content: txt,
shown: false
}
}
and get a new instance with: var myTip = new Tip("my epic tip");
This is similar to, say, c#:
public class Tip {
string text = "";
public Tip(string txt) {
text = txt;
}
}
So, sort of. 1) You're calling new since the function is essentially acting as a class, and 2) this is referring to the current instance of the class.
In fact, every data types like array, functions are Objects.
When we take function as a class declaration, this works.