I've one deep confusion in javascript regarding constructors. Here you go -
objects in javascript are created from the constructors, right?
and constructors are created from the constructor function, right?
and functions in javascript are also objects but functions in javascript are also created from the Function constructor, right?
So to be purely specific is it okay to say constructors in javascript are objects or is it wrong to say like that?
So, in the end, what will you call these, to be pure specific, just constructors or objects?
Math
Number
Array
Object
I've seen on MDN documentation these are listed under pre-built objects. Does that conclude constructors are objects?
Also, it is mentioned everywhere that in javascript everything is an object.
So could anyone please clarify for me if is it okay to say constructors are also objects in javascript?
If it is yes then, HOW DOES A CONSTRUCTOR BECOMES OBJECT (and vice versa) IN JAVASCRIPT, PLEASE THROW SOME LIGHT?
I was recently reading some tutorials of JavaScript, and every article states that Functions descend from Objects.
The above statements leads to an understanding that Objects were created before Functions were available.
If it is so, then how can constructor of an Object be a function (As per my understanding object Function hasn't been created yet)?
Please help me out with this confusion.
Functions Descend from Objects
In JavaScript functions are basically objects.
They are what is called first class objects - meaning they can do anything that an object can and are basically interchangeable.
Therefore all properties and methods available on the object level are also available on the function level.
You might want to read this
How can constructor of an Object be a function
The short answer is that you are trying to understand something that is irrelevant to understand in order for you to use the Javascript language for coding.
The longer answer is that you must distinguish between built-in objects:
Object
Function
Array
and the objects you create yourself as part of your code.
The built-in objects are part of the Javascript language and are simply available to you out-of-the-box. Your question relates to the internal workings of the language as you are inquiring about how the built-in Object is constructed. This has little value to understand unless you are looking to become part of the team developing the Javascript language.
The objects you create yourself as part of your code is almost always linked to other objects via the objects internal [[Prototype]] property. So if you for example do:
var x = {"foo": "bar"};
you have now created your own object with the property foo and the value bar. You can then do:
console.log(x.hasOwnProperty("foo")); //true
even though x does not have a method called .hasOwnProperty() directly on it. The reason the above code works is, that x is linked to the built-in Object.prototype via x's internal [[Prototype]] property and via this link delegates to Object.prototype.hasOwnProperty(). So all the objects you create as part of your code has access to use the methods on Object.prototype.
I was doing a little reading up on OOP in JavaScript and was learning a bit about using the prototype object. In this article (a very good read, btw), the author says the following regarding declaring methods as attributes of a JavaScript class versus declaring the method on the prototype of the class:
This is actually not the optimal way to do it. A better way is to define the method on Person.prototype. Why is this better? Anyone? Anyone? Beuller? In the first version, each time you create a person, a new sayHi function will be created for him, where as in the second version, only one sayHi function is ever created, and is shared amongst all persons that are created - because Person.prototype is their parent. Thus, declaring methods on the prototype is more memory efficient.
After reading this, I began to thing about a JavaScript framework that I occasionally use to ease OOP with the language, Classy. In the examples given in their documents, and in pretty much all Classy code that I've ever written, I always declared the methods of a class directly as an attribute of it (as in right between the curly brackets instead of outside). I realize that directly declaring a method of a Classy class is done via object notation (JSON) instead of a normal JavaScript class having methods added directly inside of the function of the class.
What I am wondering is if objects created with Classy already take advantage of the performance savings of a method declared against a class's prototype. If I declare class methods in the same way as Classy's documentation, are the methods declared per instance of the class or declared as one method for all instances of the class to share? If the former, then am I able to, or supposed to, declare methods in a Classy class's prototype?
Sorry if I sound confusing.
Using Codeacadamy to gain an understanding with JavaScript. I have reached a point where prototypes are having a big impact in all I code.
I understand that in simple terms, prototypes are a way of adding methods or properties to a class. Is it not just more convenient to find the original class and just pop the property / method into it instead before you lose track of whats where?
Actually, there are no real classes in javascript as you can have them in Java or C++. All you have are some sort of fake classes.
There are several ways to give javascript variables an object behaviour, and prototype is one of them. The other two are using object literals (as if you were writing a json object) and using a singleton function.
You can see a very good explanation here: http://www.phpied.com/3-ways-to-define-a-javascript-class/
One of the major advantages with Javascript is said to be that it is a prototype based language.
But what does it mean that Javascript is prototype based, and why is that an advantage?
Prototypal inheritance is a form of object-oriented code reuse. Javascript is one of the only [mainstream] object-oriented languages to use prototypal inheritance. Almost all other object-oriented languages are classical.
In classical inheritance, the programmer writes a class, which defines an object. Multiple objects can be instantiated from the same class, so you have code in one place which describes several objects in your program. Classes can then be organized into a hierarchy, furthering code reuse. More general code is stored in a higher-level class, from which lower level classes inherit. This means that an object is sharing code with other objects of the same class, as well as with its parent classes.
In the prototypal inheritance form, objects inherit directly from other objects. All of the business about classes goes away. If you want an object, you just write an object. But code reuse is still a valuable thing, so objects are allowed to be linked together in a hierarchy. In javascript, every object has a secret link to the object which created it, forming a chain. When an object is asked for a property that it does not have, its parent object will be asked... continually up the chain until the property is found or until the root object is reached.
Each function in JavaScript (which are objects themselves) actually has a member called "prototype", which is responsible for providing values when an object is asked for them. Having this member allows the constructor mechanism (by which objects are constructed from functions) to work. Adding a property to the prototype of a function object will make it available to the constructed object, as well as to all of the objects which inherit from it.
Advantages
There may not be a hard and fast rule as to why prototypal inheritance is an advantageous form of code-reuse. Code reuse itself is advantageous, and prototypal inheritance is a sensible way of going about it. You might argue that prototypal inheritance is a fairly simple model of code reuse, and that code can be heavily reused in direct ways. But classical languages are certainly able to accomplish this as well.
Sidenote: #Andrew Hedges makes a good point, that there are actually many prototypal languages. It's worth noting that these others exist, but also worth noting that none of them are anything close to mainstream. NewtonScript seemed to have some traction for a while, but died with its platform. It's also possible to extend some modern languages in ways which add prototypal capabilities.
A prototype-based language, does not make the distinction of classes vs objects: 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.
Prototype-based programming is a style of object-oriented programming where classes are not present, and behavior reuse (or inheritance in class-based languages) is performed by cloning existing objects that serve as prototypes.
The advantage/disadvantage is that, we can create new kinds of objects at run time without need for defining classes (static code). Like most features it is upto the developer to turn it to a advantage/disadvantage.
Above is possible because objects are essentially functions in java script (closures too).
Instead of declaring a class structure, you can create objects of the same type, and add to their definition any time you like using the object's prototype.
It's more flexible than the normal way of doing things.
After reading all the answers this is the conclusion
1) Inheritance in which objects are inherited directly from other objects
2) That does not use classes
3) Also called instance based programming or classless prototype oriented programming
4) Behaviour reuse is performed by cloning existing objects that serve as prototypes
5) Object used as template from the new object get initial properties
If you just use objects at runtime instead of a class at compile to build new objects, this opens up the possibility of extending an object without knowing any details about it. Of course, it may become a disadvantage pretty quickly depending on usage. I make no assumptions about the language here, so it is applicable to languages other than javascript which are not as dynamic.
myobject.prototype=unkownobject;
myobject.newproperty=1;
You may get the object from just about anywhere; your own code, from the network, from the database, from external linkage and so on.
Note that, a language don't have to implement prototype inheritance like javascript. In javascript, a prototype object is merely shared, so is its properties, among the inheritors. The alternative is copying over all the properties of the prototype to the new object. Each approach has its strengths in different situations. I like the second more but it isn't what javascript does.
Memory conservation is one of the benefits of prototypal inheritance in JS. In a language like Java, objects generate their own copies of the superclass' instance variables and methods, while in JS, the "super"-object offers get-access to its variables and methods to each "sub"-object that inherits from it without the need to recreate them.