Enumerability is one of the three attributes of a property: writability, enumerability, and configurability. My questions are:

 - What are the benefit of making properties non-enumerable in JavaScript? I know we are hiding the property by making them non-enumerable, but what are the benefit of property hiding?
 - Can we access non-enumerable properties? If yes, then what is the benefit of making them non-enumerable?
 - Are all predefined properties of Objects set as non-enumerable? Such as the case of Array&#39;s `pop` and `push` properties being non-enumerable?

What are the benefits of making properties non-enumerable?

In some of my own older code, I use the following:

    Object.prototype.instanceOf = function( iface )
    {
     return iface.prototype.isPrototypeOf( this );
    };

Then I do (for example)

    [].instanceOf( Array )

This works, but it seems the following would do the same:

    [] instanceof Array

Now, surely this is only a very simple example. My question therefore is:

Is `a instanceof b` *ALWAYS* the same as `b.prototype.isPrototypeOf(a)` ?



What&#39;s the difference between isPrototypeOf and instanceof in Javascript?

What does the following code do:

    WeatherWidget.prototype = new Widget;

where `Widget` is a constructor, and I want to extend the Widget &#39;class&#39; with a new function `WeatherWidget`.

What is the **`new`** keyword doing there and what would happen if it is left out? 

What is the reason to use the &#39;new&#39; keyword at Derived.prototype = new Base

I&#39;m new to JavaScript ,to understand this concept i have read many articles regarding prototype and constructors but where ever i go i&#39;m left with confusion.

The confusion arises when people talk about constructor and prototype simultaneously.

In the following example 

    var employee = function Emp(name) {
        this.name = name;
    }
    var jack = new employee(&quot;Jack Dwain&quot;);
    
    employee.constructor //gives Function()
    
    employee.prototype // gives  Emp {}
    
    employee.prototype.constructor //gives Emp(name)
    
    jack.constructor //gives Emp(name)
    
    jack.prototype //gives undefined

1. prototype is a way JS achieves inheritance,since `Emp(name)` is the base function prototype is referenced to the same function itself. Is that what happened?


2. In what way `employee.constructor` and `employee.prototype.constructor` differ?

3. Why was `jack.prototype` is `undefined` i.e If it is inheriting from the function `Emp(name)` why it didn&#39;t reference that function?

4. How can I clearly predict  myself without typing in the console what the prototype or the constructor or the prototype.constructor ......yields

Trying to understand the difference between prototype and constructor in JavaScript

When ES6 Arrow functions don&#39;t seem to work for assigning a function to an object with prototype.object. Consider the following examples:

    function Animal(name, type){
     this.name = name;
      this.type = type;
      this.toString = () =&gt; `${this.name} is a ${this.type}`;
      
    }
    var myDog = new Animal(&#39;Max&#39;, &#39;Dog&#39;);
    console.log(myDog.toString()); //Max is a Dog

Using the arrow function explicitly in the object definition works, but using the arrow functions with the Object.prototype syntax does not:

    function Animal2(name, type){
      this.name = name;
      this.type = type;
    }
    Animal2.prototype.toString = () =&gt; `${this.name} is a ${this.type}`;
    
    var myPet2 = new Animal2(&#39;Noah&#39;, &#39;cat&#39;);
    console.log(myPet2.toString()); //is a undefined

Just as a proof of concept, using the Template string syntax with Object.prototype syntax does work:

    function Animal3(name, type){
      this.name = name;
      this.type = type;
    }
    Animal3.prototype.toString = function(){ return `${this.name} is a ${this.type}`;}
    
    var myPet3 = new Animal3(&#39;Joey&#39;, &#39;Kangaroo&#39;);
    console.log(myPet3.toString()); //Joey is a Kangaroo

Am I missing something obvious? I feel that example 2 should work logically, but I am puzzled by the output. I&#39;m guessing it is a scoping issue, but I am thrown off by the output &#39;is a undefined&#39;.

[ES6 Fiddle][1]


  [1]: http://www.es6fiddle.net/ics4dh0m/

ES6 arrow functions not working on the prototype?

The [API Reference Scope page][1] says:

&gt; A scope *can* inherit from a parent scope.

The [Developer Guide Scope page][2] says:

&gt; A scope (prototypically) inherits properties from its parent scope.

 - So, does a child scope always prototypically inherit from its parent scope?  
 - Are there exceptions?   
 - When it does inherit, is it always normal JavaScript prototypal inheritance?

  [1]: http://docs.angularjs.org/api/ng.$rootScope.Scope
  [2]: http://docs.angularjs.org/guide/scope





What are the nuances of scope prototypal / prototypical inheritance in AngularJS?

&gt; This figure again shows that every object has a prototype. Constructor
&gt; function Foo also has its own `__proto__` which is Function.prototype,
&gt; and which in turn also references via its `__proto__` property again to
&gt; the Object.prototype. Thus, repeat, Foo.prototype is just an explicit
&gt; property of Foo which refers to the prototype of b and c objects.

    var b = new Foo(20);
    var c = new Foo(30);

What are the differences between `__proto__` and `prototype`?


![enter image description here][2]

The figure was taken from [dmitrysoshnikov.com][1].

*Note:  there is now [a 2nd edition (2017)][3] to the above 2010 article.*    

  [1]: http://dmitrysoshnikov.com/ecmascript/javascript-the-core/
  [2]: http://i.stack.imgur.com/UfXRZ.png
  [3]: http://dmitrysoshnikov.com/ecmascript/javascript-the-core-2nd-edition/

__proto__ VS. prototype in JavaScript

I know how to parse a JSON String and turn it into a JavaScript Object. 
 You can use `JSON.parse()` in modern browsers (and IE9+).

That&#39;s great, but how can I take that JavaScript Object and turn it into a *particular* JavaScript Object (i.e. with a certain prototype)?

For example, suppose you have:

    function Foo()
    {
       this.a = 3;
       this.b = 2;
       this.test = function() {return this.a*this.b;};
    }
    var fooObj = new Foo();
    alert(fooObj.test() ); //Prints 6
    var fooJSON = JSON.parse({&quot;a&quot;:4, &quot;b&quot;: 3});
    //Something to convert fooJSON into a Foo Object
    //....... (this is what I am missing)
    alert(fooJSON.test() ); //Prints 12

Again, I am not wondering how to convert a JSON string into a generic JavaScript Object.  I want to know how to convert a JSON string into a &quot;Foo&quot; Object.  That is, my Object should now have a function &#39;test&#39; and properties &#39;a&#39; and &#39;b&#39;.

**UPDATE**
After doing some research, I thought of this...

    Object.cast = function cast(rawObj, constructor)
    {
        var obj = new constructor();
        for(var i in rawObj)
            obj[i] = rawObj[i];
        return obj;
    }
    var fooJSON = Object.cast({&quot;a&quot;:4, &quot;b&quot;: 3}, Foo);

Will that work?

**UPDATE May, 2017**: The &quot;modern&quot; way of doing this, is via [`Object.assign`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign), but this function is not available in IE 11 or older Android browsers.

Parse JSON String into a Particular Object Prototype in JavaScript

What&#39;s the difference between

    var A = function () {
        this.x = function () {
            //do something
        };
    };

and

    var A = function () { };
    A.prototype.x = function () {
        //do something
    };

Use of &#39;prototype&#39; vs. &#39;this&#39; in JavaScript?

I am currently transforming from `Java` to `Javascript`, and it&#39;s a bit hard for me to figure out how to extend objects the way I want it to do.

I&#39;ve seen several people on the internet use a method called extend on object. The code will look like this:

    var Person = {
       name : &#39;Blank&#39;,
       age  : 22
    }
    
    var Robot = Person.extend({
       name : &#39;Robo&#39;,
       age  : 4
    )}

    var robot = new Robot();
    alert(robot.name); //Should return &#39;Robo&#39;
Does anyone know how to make this work?
I&#39;ve heard that you need to write 

    Object.prototype.extend = function(...);

But I don&#39;t know how to make this system work. If it is not possible, please show me another alternative that extends an object.

Extending an Object in Javascript

Using Spring&#39;s Java Config, I need to acquire/instantiate a prototype-scoped bean with constructor arguments that are only obtainable at runtime.  Consider the following code example (simplified for brevity):

    @Autowired
    private ApplicationContext appCtx;
    
    public void onRequest(Request request) {
        //request is already validated
        String name = request.getParameter(&quot;name&quot;);
        Thing thing = appCtx.getBean(Thing.class, name);
 
        //System.out.println(thing.getName()); //prints name
    }

where the Thing class is defined as follows:

    public class Thing {
    
        private final String name;

        @Autowired
        private SomeComponent someComponent;

        @Autowired
        private AnotherComponent anotherComponent;

        public Thing(String name) {
            this.name = name;
        }

        public String getName() {
            return this.name;
        }
    }

Notice `name` is `final`: it can only be supplied via a constructor, and guarantees immutability.  The other dependencies are implementation-specific dependencies of the `Thing` class, and shouldn&#39;t be known to (tightly coupled to) the request handler implementation.

This code works perfectly well with Spring XML config, for example:

    &lt;bean id=&quot;thing&quot;, class=&quot;com.whatever.Thing&quot; scope=&quot;prototype&quot;&gt;
        &lt;!-- other post-instantiation properties omitted --&gt;
    &lt;/bean&gt;

How do I achieve the same thing with Java config?  The following does not work using Spring 3.x:

    @Bean
    @Scope(&quot;prototype&quot;)
    public Thing thing(String name) {
        return new Thing(name);
    }

Now, I *could* create a Factory, e.g.:

    public interface ThingFactory {
        public Thing createThing(String name);
    }

But that _defeats the entire point of using Spring to replace the ServiceLocator and Factory design pattern_, which would be ideal for this use case.

If Spring Java Config could do this, I would be able to avoid:

* defining a Factory interface
* defining a Factory implementation
* writing tests for the Factory implementation

That&#39;s a ton of work (relatively speaking) for something so trivial that Spring already supports via XML config.

Spring Java Config: how do you create a prototype-scoped @Bean with runtime arguments?

Every JS opinion leader says that extending the native objects is a bad practice. But why? Do we get a perfomance hit? Do they fear that somebody does it &quot;the wrong way&quot;, and adds enumerable types to `Object`, practically destroying all loops on any object?

Take [TJ Holowaychuk](https://github.com/visionmedia)&#39;s [should.js](https://github.com/visionmedia/should.js) for example. He [adds a simple getter](https://github.com/visionmedia/should.js#omg-it-extends-object) to `Object` and everything works fine ([source](https://github.com/visionmedia/should.js/blob/master/lib/should.js#L66-78)).

    Object.defineProperty(Object.prototype, &#39;should&#39;, {
      set: function(){},
      get: function(){
        return new Assertion(Object(this).valueOf());
      },
      configurable: true
    });

This really makes sense. For instance one could extend `Array`.

    Array.defineProperty(Array.prototype, &quot;remove&quot;, {
      set: function(){},
      get: function(){
        return removeArrayElement.bind(this);
      }
    });
    var arr = [0, 1, 2, 3, 4];
    arr.remove(3);

Are there any arguments against extending native types?


Why is extending native objects a bad practice?

I&#39;ve come to a point where I need to have some sort of rudimentary multiple inheritance happening in JavaScript. (I&#39;m not here to discuss whether this is a good idea or not, so please kindly keep those comments to yourself.)

I just want to know if anyone&#39;s attempted this with any (or not) success, and how they went about it.

To boil it down, what I really need is to be able to have an object capable of inheriting a property from more than one prototype *chain* (i.e. each prototype could have its own proper chain), but in a given order of precedence (it will search the chains in order for the first definition).

To demonstrate how this is theoretically possible, it could be achieved by attaching the secondary chain onto the end of the primary chain, but this would affect all instances of any of those previous prototypes and that&#39;s not what I want.

Thoughts?

Multiple inheritance/prototypes in JavaScript

So I have these 2 examples, from javascript.info:

Example 1:

    var animal = {
      eat: function() {
        alert( &quot;I&#39;m full&quot; )
        this.full = true
      }
    }
     
    var rabbit = {
      jump: function() { /* something */ }
    }
     
    rabbit.__proto__ = animal 
     
    rabbit.eat() 

Example 2:

    function Hamster() {  }
    Hamster.prototype = {
      food: [],
      found: function(something) {
        this.food.push(something)
      }
    }
     
    // Create two speedy and lazy hamsters, then feed the first one
    speedy = new Hamster()
    lazy = new Hamster()
     
    speedy.found(&quot;apple&quot;)
    speedy.found(&quot;orange&quot;)
     
    alert(speedy.food.length) // 2
    alert(lazy.food.length) // 2 (!??)


Start from Example 2: when the code reaches `speedy.found`, it finds no `found` property in `speedy`, and so it climbs up to the prototype and changes it there. That&#39;s why `food.length` is equal for both hamsters, in other words they have the same stomach.&lt;br&gt;&lt;br&gt;
From this I understand, that when writing up and adding a new property which doesn&#39;t exist, the interpreter will go up the prototype chain until it finds the property, and THEN change it.


BUT in Example 1 something else happens:&lt;br&gt;
we run `rabbit.eat`, which changes `rabbit.full`. `full` property is nowhere to be found, so it should go up the prototype chain to (to object??), and well, I&#39;m not sure what happens here. In this example the property `full` of `rabbit` is created and changed, while in the first example it goes up the prototype chain because it cannot find the property.


I&#39;m confused and cannot see why this happens.

Prototypical inheritance - writing up

Is it possible to call the base method from a prototype method in JavaScript if it&#39;s been overridden?

    MyClass = function(name){
        this.name = name;
        this.do = function() {
            //do somthing 
        }
    };

    MyClass.prototype.do = function() {  
        if (this.name === &#39;something&#39;) {
            //do something new
        } else {
            //CALL BASE METHOD
        }
    };


Calling method using JavaScript prototype

I am relatively new to JavaScript and keep seeing .extend and .prototype in third party libraries I am using. I thought it had to do with the Prototype javascript library, but I am beginning to think that is not the case. What are these used for?

JavaScript: What are .extend and .prototype used for?

Trying to bend by head around Javascript&#39;s take on OO...and, like many others, running into confusion about the `constructor` property. In particular, the significance of the `constructor` property, as I can&#39;t seem to make it have any effect. E.g.:

    function Foo(age) {
        this.age = age;
    }
     
    function Bar() {
        Foo.call(this, 42);
        this.name = &quot;baz&quot;; 
    }
 
    Bar.prototype = Object.create(Foo.prototype); 
    var b = new Bar;    

    alert(b.constructor); // &quot;Foo&quot;. That&#39;s OK because we inherit `Foo`&#39;s prototype.
    alert(b.name);        // &quot;baz&quot;. Shows that Bar() was called as constructor.
    alert(b.age);         // &quot;42&quot;, inherited from `Foo`.

In the above example, the object `b` seems to have had the right constructor called (`Bar`) &amp;ndash; and it inherits the age property from `Foo`. So why do many people suggest this as a necessary step:

    Bar.prototype.constructor = Bar;

Clearly, the right `Bar` constructor *was* called when constructing `b`, so what impact does this prototype property have? I am curious to know what practical difference it actually makes to have the constructor property set &#39;correctly&#39;—as I can&#39;t see it having any affect on which constructor is actually called after an object is created.

What is the significance of the Javascript constructor property?

In [another Stack&amp;nbsp;Overflow question][1] [Leon Timmermans](https://stackoverflow.com/users/4727/leon-timmermans) asserted:

&gt; I would advice you not to use prototypes. They have their uses, but not for most cases and definitely not in this one.

Why might this be true (or otherwise)? I almost always supply prototypes for my Perl functions, and I&#39;ve never before seen anyone else say anything bad about using them.

  [1]: https://stackoverflow.com/questions/204467/is-there-a-perl-function-to-turn-a-string-into-a-regexp-to-use-that-string-as-p




Why are Perl 5&#39;s function prototypes bad?

I have two controllers, one wrapped within another. Now I know the child scope inherits properties from the parent scope but is there a way to update the parent scope variable? So far I have not come across any obvious solutions.

In my situation I have a calendar controller within a form. I would like to update the start and end dates from the parent scope (which is the form) so that the form has the start and end dates when submitted.

Update parent scope variable in AngularJS

I&#39;m new to JavaScript. New as far as all I&#39;ve really done with it is tweaked existing code and wrote small bits of jQuery.

Now I&#39;m attempting to write a &quot;class&quot; with attributes and methods, but I&#39;m having trouble with the methods. My code: 


    
    function Request(destination, stay_open) {
        this.state = &quot;ready&quot;;
        this.xhr = null;
        this.destination = destination;
        this.stay_open = stay_open;
		
        this.open = function(data) {
            this.xhr = $.ajax({
                url: destination,
                success: this.handle_response,
                error: this.handle_failure,
                timeout: 100000000,
                data: data,
                dataType: &#39;json&#39;,
            });
        };
	
        /* snip... */

    }

    Request.prototype.start = function() {
        if( this.stay_open == true ) {
            this.open({msg: &#39;listen&#39;});
        } else {
    
        }
    };
    //all console.log&#39;s omitted

The problem is, in `Request.prototype.start`, `this` is undefined and thus the if statement evaluates to false. What am I doing wrong here? 

&#39;this&#39; is undefined in JavaScript class methods

I&#39;d like to understand when it is appropriate to use prototype methods in js.  Should they always be used? Or are there cases where using them is not preferred and/or incurs a performance penalty?  

In searching around this site on common methods for namespacing in js, it seems that most use a non-prototype based implementation: simply using an object or a function object to encapsulate a namespace.  

Coming from a class-based language, it&#39;s hard not to try and draw parallels and think that prototypes are like &quot;classes&quot; and the namespace implementations I mentioned are like static methods.  

Javascript when to use prototypes

The only difference I see in map and foreach is that `map` is returning an array and `forEach` is not. However, I don&#39;t even understand the last line of the `forEach` method &quot;`func.call(scope, this[i], i, this);`&quot;. For example, isn&#39;t &quot;`this`&quot; and &quot;`scope`&quot; referring to same object and isn&#39;t `this[i]` and `i` referring to the current value in the loop?

I noticed on another post someone said &quot;Use `forEach` when you want to do something on the basis of each element of the list. You might be adding things to the page, for example. Essentially, it&#39;s great for when you want &quot;side effects&quot;. I don&#39;t know what is meant by side effects.

    Array.prototype.map = function(fnc) {
        var a = new Array(this.length);
        for (var i = 0; i &lt; this.length; i++) {
            a[i] = fnc(this[i]);
        }
        return a;
    }

    Array.prototype.forEach = function(func, scope) {
        scope = scope || this;
        for (var i = 0, l = this.length; i &lt; l; i++) {
            func.call(scope, this[i], i, this);
        }
    }

Finally, are there any real uses for these methods in JavaScript (since we aren&#39;t updating a database) other than to manipulate numbers like the following?

    alert([1,2,3,4].map(function(x){ return x + 1})); // This is the only example I ever see of map in JavaScript.


What use does the JavaScript forEach method have (that map can&#39;t do)?

I recently stumbled upon the `Object.create()` method in JavaScript, and am trying to deduce how it is different from creating a new instance of an object with `new SomeFunction()`, and when you would want to use one over the other.

Consider the following example:

&lt;!-- begin snippet: js hide: false console: true babel: false --&gt;

&lt;!-- language: lang-js --&gt;

    var test = {
      val: 1,
      func: function() {
        return this.val;
      }
    };
    var testA = Object.create(test);

    testA.val = 2;
    console.log(test.func()); // 1
    console.log(testA.func()); // 2

    console.log(&#39;other test&#39;);
    var otherTest = function() {
      this.val = 1;
      this.func = function() {
        return this.val;
      };
    };

    var otherTestA = new otherTest();
    var otherTestB = new otherTest();
    otherTestB.val = 2;
    console.log(otherTestA.val); // 1 
    console.log(otherTestB.val); // 2

    console.log(otherTestA.func()); // 1
    console.log(otherTestB.func()); // 2

&lt;!-- end snippet --&gt;

Notice that the same behaviour is observed in both cases.  It seems to me that the primary differences between these two scenarios are:

 - The object used in `Object.create()` actually forms the prototype of the new object, whereas in the `new Function()` from the declared properties/functions do not form the prototype.  
 - You cannot create closures with the `Object.create()` syntax as you would with the functional syntax.  This is logical given the lexical (vs block) type scope of JavaScript.

Are the above statements correct? And am I missing something?  When would you use one over the other?  


EDIT: link to jsfiddle version of above code sample: [http://jsfiddle.net/rZfYL/][1]


  [1]: http://jsfiddle.net/rZfYL/

Understanding the difference between Object.create() and new SomeFunction()

In all the articles it is written that JavaScript is a prototype-based language, meaning that every object has a prototype (or, more precisely, prototype chain).

So far, I&#39;ve tried the following code snippet:

    var F = function();
    F.prototype.member1 = 1;
    var object1 = new F();
    console.log(object1.member1); // prints 1

How can I access the prototype object of `object1`? Is there a browser-neutral way to do that (I mean, not relying on `__proto__` property? Seen [this][1] link, but maybe there are new developments since 2010) If I can&#39;t, could you share please the rationale behind the hood?


  [1]: https://stackoverflow.com/questions/2242518/how-can-i-see-a-javascript-objects-prototype-chain

How to access object prototype in javascript?

I have such example.

    function Rabbit() {
    	var jumps = &quot;yes&quot;;
    };
    var rabbit = new Rabbit();
    alert(rabbit.jumps);                    // undefined
    alert(Rabbit.prototype.constructor);    // outputs exactly the code of the function Rabbit();


I want to change the code in `Rabbit()` so that the `var jumps` becomes public. I do it this way:

    Rabbit.prototype.constructor = function Rabbit() {
    	this.jumps = &quot;no&quot;;
    };
    alert(Rabbit.prototype.constructor);    // again outputs the code of function Rabbit() and with new this.jumps = &quot;no&quot;;
    var rabbit2 = new Rabbit();             // create new object with new constructor
    alert(rabbit2.jumps);                   // but still outputs undefined

Why is it not possible to change the code in constructor function this way?


Why is it impossible to change constructor function from prototype?

I&#39;m fairly new to the concept of JavaScript&#39;s prototype concept. 

Considering the following code : 

    var x = function func(){
    }
    
    x.prototype.log = function() {
      console.log(&quot;1&quot;);
    }
    
    var b = new x();

As I understand it, `b.log()` should return 1 since `x` is its prototype. But why is the property `b.prototype` undefined?

Isn&#39;t `b.prototype` supposed to return the reference to the `x` function?


Why is JavaScript prototype property undefined on new objects?

The prototype system looks much more flexible than the traditional class system, but people seem to feel content with the so-called &quot;best practices&quot;, which mimic the traditional class system:

    function foo() {
      // define instance properties here
    }
    
    foo.prototype.method = //define instance method here
    
    new foo()

There must be other things that a prototypal system can do with all the flexibility.

Are there uses for a prototypal system outside of mimicking classes? What kinds of things can prototypes do which classes cannot, or are there none?

What can the JavaScript prototype system do beyond mimicking a classical class system?

I&#39;m currently enjoying the transition from an object oriented language to a functional language. It&#39;s a breath of fresh air, and I&#39;m finding myself much more productive than before.

However - there is one aspect of OOP that I&#39;ve not yet seen a satisfactory answer for on the FP side, and that is **polymorphism**. i.e. I have a large collection of data items, which need to be processed in quite different ways when they are passed into certain functions. For the sake of argument, let&#39;s say that there are multiple factors driving polymorphic behaviour so potentially exponentially many different behaviour combinations.

In OOP that can be handled relatively well using polymorphism: either through composition+inheritance or a prototype-based approach.

In FP I&#39;m a bit stuck between:

 - Writing or composing pure functions that effectively implement polymorphic behaviours by branching on the value of each data item - feels rather like assembling a huge conditional or even simulating a virtual method table! 
 - Putting functions inside pure data structures in a prototype-like fashion - this seems like it works but doesn&#39;t it also violate the idea of defining pure functions separately from data?

What are the recommended functional approaches for this kind of situation? Are there other good alternatives?


Achieving polymorphism in functional programming

In JavaScript, we have two ways of making a &quot;class&quot; and giving it public functions. 

Method 1:

    function MyClass() {
        var privateInstanceVariable = &#39;foo&#39;;
        this.myFunc = function() { alert(privateInstanceVariable ); }
    }

Method 2:

    function MyClass() { }
    
    MyClass.prototype.myFunc = function() { 
        alert(&quot;I can&#39;t use private instance variables. :(&quot;); 
    }

I&#39;ve read numerous times people [saying][1] that using Method 2 is more efficient as all instances share the same copy of the function rather than each getting their own. Defining functions via the prototype has a huge disadvantage though - it makes it impossible to have private instance variables. 

Even though, in theory, using Method 1 gives each instance of an object its own copy of the function (and thus uses way more memory, not to mention the time required for allocations) - is that what actually happens in practice? It seems like an optimization web browsers could easily make is to recognize this extremely common pattern, and actually have all instances of the object reference *the same* copy of functions defined via these &quot;constructor functions&quot;. Then it could only give an instance its own copy of the function if it is explicitly changed later on.

Any insight - or, even better, *real world experience* - about performance differences between the two, would be extremely helpful.

  [1]: https://stackoverflow.com/questions/4508313/advantages-of-using-prototype-vs-defining-methods-straight-in-the-constructor

Defining methods via prototype vs using this in the constructor - really a performance difference?

I am confused with this code below,

    Developer devCopy = (Developer)dev.Clone();

Clone method of Developer class just creating a Employee clone, then how developer get another clone of developer. 

    public abstract class Employee
    {
        public abstract Employee Clone();
    
        public string Name { get; set; }
        public string Role { get; set; }
    }
    
    
    public class Typist : Employee
    {
        public int WordsPerMinute { get; set; }
    
        public override Employee Clone()
        {
            return (Employee)MemberwiseClone();
        }
    
        public override string ToString()
        {
            return string.Format(&quot;{0} - {1} - {2}wpm&quot;, Name, Role, WordsPerMinute);
        }
    }
    
    
    public class Developer : Employee
    {
        public string PreferredLanguage { get; set; }
    
        public override Employee Clone()
        {
            return (Employee)MemberwiseClone();
        }
    
        public override string ToString()
        {
            return string.Format(&quot;{0} - {1} - {2}&quot;, Name, Role, PreferredLanguage);
        }
    }


    Developer dev = new Developer();
    dev.Name = &quot;Bob&quot;;
    dev.Role = &quot;Team Leader&quot;;
    dev.PreferredLanguage = &quot;C#&quot;;
    
    Developer devCopy = (Developer)dev.Clone();
    devCopy.Name = &quot;Sue&quot;;
    
    Console.WriteLine(dev);
    Console.WriteLine(devCopy);
    
    /* OUTPUT
    
    Bob - Team Leader - C#
    Sue - Team Leader - C#
    
    */
    
    Typist typist = new Typist();
    typist.Name = &quot;Kay&quot;;
    typist.Role = &quot;Typist&quot;;
    typist.WordsPerMinute = 120;
    
    Typist typistCopy = (Typist)typist.Clone();
    typistCopy.Name = &quot;Tim&quot;;
    typistCopy.WordsPerMinute = 115;
    
    Console.WriteLine(typist);
    Console.WriteLine(typistCopy);
    
    /* OUTPUT
    
    Kay - Typist - 120wpm
    Tim - Typist - 115wpm
    
    */



What is the method MemberwiseClone() doing?

Calling one prototype method inside another in javascript

From the MDN docs for the *standard* [`setPrototypeOf` function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/setPrototypeOf)  as well as the non-standard [ `__proto__` property](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto):
&gt; Mutating the [[Prototype]] of an object, no matter how this is accomplished, is strongly discouraged, because it is very slow and unavoidably slows down subsequent execution in modern JavaScript implementations.



Using `Function.prototype` to add properties is *the* way to add member functions to javascript classes. Then as the following shows: 

    function Foo(){}
    function bar(){}
    
    var foo = new Foo();
    
    // This is bad: 
    //foo.__proto__.bar = bar;
    
    // But this is okay
    Foo.prototype.bar = bar;
    
    // Both cause this to be true: 
    console.log(foo.__proto__.bar == bar); // true

Why is `foo.__proto__.bar = bar;` bad? If its bad isn&#39;t `Foo.prototype.bar = bar;` just as bad? 

Then why this warning: ***it is very slow and unavoidably slows down subsequent execution in modern JavaScript implementations***. Surely `Foo.prototype.bar = bar;` is not that bad.


**Update** Perhaps by mutation they meant reassignment. See accepted answer. 

Why is mutating the [[prototype]] of an object bad for performance?

Consider this function:

    function Foo(){
        var a = &quot;3&quot;;
    };

According to *https://stackoverflow.com/questions/9959727/proto-vs-prototype-in-javascript*,

    Foo.__proto__ = Function.prototype
    Function.prototype.__proto__ = Object.prototype

I understood that part, but if I do this in the Google Chrome console:

    Object.__proto__
    output: ƒ () { /* native code */ }

    Function.__proto__
    output: ƒ () { /* native code */ }

**Q1:** Why are they pointing to Function? What actually are `Function` and `Object` and how are they different from each other, because **`Object` is actually a function**?:

    typeof Object
    &quot;function&quot;

**Q2:** If everything is an object in JavaScript, then why is `Object` a function? Also, how is a function actually implemented inside JavaScript? What happens to the variables declared inside a function? Is a function converted into an object by the JavaScript compiler?

Sorry if I am missing something obvious. I am really confused by the way function and object are implemented in JavaScript.


Is `Object` a function in JavaScript?

Google JavaScript Style Guide [advises against extending the `Array.prototype`][1].
However, I used `Array.prototype.filter = Array.prototype.filter || function(...) {...}` as a way to have it (and similar methods) in browsers where they do not exist. MDN actually provides [similar example][2].

I am aware about `Object.prototype` issues, but `Array` is not a hash table.

What issues may arise while extending `Array.prototype` that made Google advise against it?  


  [1]: https://google.github.io/styleguide/jsguide.html#disallowed-features-modifying-builtin-objects
  [2]: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/filter#Compatibility

JavaScript: What dangers are in extending Array.prototype?

I am wondering if there are any advantages of using any of these over the other, and which way should I go?

Constructor approach:

    var Class = function () {
       
        this.calc = function (a, b) {
            return a + b;
        };
       
    };

Prototype approach:

    var Class = function () {};

    Class.prototype.calc = function (a, b) {
        return a + b;
    };

I don&#39;t like that, using the prototype, method definitions are separated from the class, and I&#39;m not aware if there is any specific reason I should use this over just the first approach.

Also, is there any benefit of using a function literal to define a &quot;class&quot;, over just function definition:

    var Class = function () {};

vs

    function Class () {};

Thanks!

Advantages of using prototype, vs defining methods straight in the constructor?

    STORE = {
       item : function() {
      }
    };
    STORE.item.prototype.add = function() { alert(&#39;test 123&#39;); };
    STORE.item.add();

I have been trying to figure out what&#39;s wrong with this quite a while. Why doesn&#39;t this work? However, it works when I use the follow:

    STORE.item.prototype.add();





All Prototype Solutions on Gang of Coders

Total of 36 Prototype Solutions