2

For creating Javascript object, we can use Literal or Constructor way; In Constructor way, we say;

function myObj(){
this.myProp1 = "abc";
this.myProp2 = "xyz";
}

In literal way, we say;

var myObj = {
myProp1:"abc",
myProp2:"xyz",
}

My question is when declaring properties, why there is a difference like why do we use "this.myProp1" in case of Constructor way and not use "this" in Literal way ?

copenndthagen
  • 49,230
  • 102
  • 290
  • 442
  • 2
    Because that's how object literal syntax is defined (http://es5.github.com/#x11.1.5)? What kind of answer do you expect? `this` is a special local variable of functions (which points to a new object when the function is called with `new`) and an object literal is not a function. – Felix Kling Feb 21 '13 at 17:36
  • But is there any specific reason or logic behind it OR it's just a syntax thing ? – copenndthagen Feb 21 '13 at 17:43
  • 2
    Isn't the logic *"`this` is a special varaible inside a function, an object literal is not a function"* enough? I'm sure if one wanted to, they could change the literal syntax to create objects like so `var obj = {this.foo: 'bar'};` but what would be the advantage? `this.` is completely redundant in this case. But I didn't design the language, maybe you should ask the questions to those who did, to get an authoritative answer. It could also be that the designers just never thought about doing it this way. – Felix Kling Feb 21 '13 at 17:47
  • And this is just one reason why I completely disagree with anyone that says JS is an OOP language... It isn't! It just fakes it! (That's what she said) – Iron3eagle Feb 21 '13 at 17:59
  • 'This' is a context pointer, it more or less defines the object that the called method is attached to - whether its an instance or static object. – CBusBus Feb 21 '13 at 18:13
  • 1
    @defaultNINJA: It is! You mistake [OOP](http://en.wikipedia.org/wiki/Object-oriented_programming) for [class-based programming](http://en.wikipedia.org/wiki/Class-based_programming) – Bergi Feb 21 '13 at 18:18
  • @Bergi "In contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program" Directly from the OOP Wiki you linked too. Tell me how you do this in JS with out doing tricks like using literals and enclosures... It's not. – Iron3eagle Feb 21 '13 at 18:27
  • 2
    @defaultNINJA JS is the quintessential OOP language. In terms of limitations imposed by a language on its ability to represent the abstract concept of objects, javascript is one of the least constrained languages available. – CBusBus Feb 21 '13 at 18:28
  • [Private members](http://javascript.crockford.com/private.html) – CBusBus Feb 21 '13 at 18:30
  • Until JS has true encapsulation and subtyping, which are two "fundamental features and concepts" of OOP, it's not a true OOP language. You can't create objects of objects and test for instancesof and keep data private, with out doing alot of tricks that DO simulate OOP very well, don't get me wrong, I use a lot of Module Patterns etc that work, but that doesn't make it OOP. – Iron3eagle Feb 21 '13 at 18:33
  • @SOliver That's not truely private, that's called scope. – Iron3eagle Feb 21 '13 at 18:34
  • @defaultNINJA Scope and visibility aren't mutually exclusive, besides the read / write interaction pattern [function f(){}] of private members prevents multi-level scoped access that may allude one to considered it scoped. – CBusBus Feb 21 '13 at 18:55
  • @defaultNINJA They're not "tricks". They're the techniques by which you achieve that. There is no requirement for an OO language to have syntactical constructs for encapsulation. Also, the claim about `instanceof` is a complete lie. `instanceof` checks the prototype chain as one would expect. – millimoose Feb 22 '13 at 19:08
  • Looks like the JavaScript fan boys are upset... sorry. – Iron3eagle Feb 22 '13 at 19:15
  • @defaultNINJA Looks like you're out of actual arguments, which should be your cue to take this trolling to slashdot. – millimoose Feb 22 '13 at 19:47
  • @millimoose What the hell is slashdot? I'm not trolling, I get this stupid red dot pop up in the top right corner when some one leaves a comment. I just find it ironic that heavy JS users are dead set that JS is OO like it's some sort of insult if it's not. Play with Objective-C and Java Objects and then tell me what you think. Anyway I'm done responding. I'm sure you'll want the last word. – Iron3eagle Feb 22 '13 at 19:52

2 Answers2

13

The key difference between the two is in how they are intended to be used. A constructor, as its name suggests, is designed to create and set up multiple instances of an object. An object literal on the other hand is one-off, like string and number literals, and used more often as configuration objects or global singletons (e.g. for namespacing).

There are a few subtleties about the first example to note:

When the code is executed, an anonymous function is created and assigned to myObj, but nothing else happens. methodOne and methodTwo don't exist until myObj is explicitly called.
Depending on how myObj is called, the methods methodOne and methodTwo will end up in different places:

myObj():
Since no context is supplied, the this defaults to window and the methods will become global.

var app1 = new myObj():
Due to the new keyword, a new object is created and becomes the default context. this refers to the new object, and the methods will get assigned to the new object, which subsequently gets assigned to app1. However, myObj.methodOne remains undefined.

myObj.call(yourApp):
This calls my myObj but sets the context to be another object, yourApp. The methods will get assigned to yourApp, overriding any properties of yourApp with the same names. This is a really flexible method that allows multiple inheritance or mixins in Javascript.

Constructors also allow another level of flexibility since functions provide closures, while object literals do not. If for example methodOne and methodTwo rely on a common variable password that is private to the object (cannot be accessed outside the constructor), this can be achieved very simply by doing:

var myObj = function(){
    var variableOne = "ABCD1234";

    this.methodOne = function(){
       // Do something with variableOne
       console.log(variableOne);
    };
    this.methodTwo = function(){
       // Do something else with variableOne
    };
};

myObj();

alert(variableOne); // undefined
alert(myObj.variableOne); // undefined

If you wanted to make variableOne exposed (public) you'd do:

var myObj = function(){
    this.variableOne = "ABCD1234";

    this.methodOne = function(){
       // Do something with variableOne
       console.log(this.variableOne);
    };
    this.methodTwo = function(){
       // Do something else with variableOne
    };
};

myObj();

alert(variableOne); // undefined
alert(myObj.variableOne); // ABCD1234   
whoan
  • 8,143
  • 4
  • 39
  • 48
Filipe Melo
  • 558
  • 5
  • 10
4

When defining something literally, the object is being built directly in the code. It doesn't exist yet until it is complete. At that point, this would have no meaning (not that there is any need for it either).

To understand this in the object creation function, first realize that this is special in JavaScript. Whenever you call a function, you can pass anything you want to be this. In general, things like event handlers will pass the event-causing DOM object to be passed as this. In your code, you do this as: MyFunction.call(whatever_needs_to_be_this[, param0, param1]);. When you use the new operator, such as var mything = new SomeThing();, JavaScript is essentially doing something like:

var mything = {};
SomeThing.call(mything);

this in this case is going to be mything in your function.

Mark Ormston
  • 1,836
  • 9
  • 13