...

View Full Version : return keyword applied on object returns reference or value?



johnmerlino
08-24-2010, 12:37 AM
I am confused about what the return keyword is actually returning when returning an object, a primitive, or a function.

My confusion is compounded by the fact that I'm not sure if a function is an object or not.
According to the book JavaScript Programmer Reference it is:
"All functions in JavaScript are first class objects , meaning they can be passed around like any other object reference. In fact, regardless of how they are created, functions are instances of a global object named (aptly) Function."

However, someone else states that a function is not an object. An object is a set of primitives and references. A function is executable code. Functions become objects through the use of the new operator. Yet, in the book I mentioned, it says you don't need the new keyword to execute the function as an object, as it already inherits from the object Function when the function keyword is used:


function functionName([argname1 [, ...[, argnameN]]])
{
statements;
}

So there's one source of contradiction.

Now the bigger issue is what is going on when the return keyword is used. Notice the Validation() function returns an object as its last expression. This technique is common, where you return an object which contains functions in form of object notation. I believe this is done so that we create a closure so that when the intepreter exits the Validation() method, since we created a closure by returning an object, which contains the inner functions addRule and getRule, the local variables of Validation() are not destroyed, given that we can reference them through the two inner functions that make use of the local variables of the outer function. So when we use the return keyword on an object literal, and then exit the function, when we call one of the inner functions as we do later:


var rule = $.Validation.getRule(types[type]);

essentially getRule() is called, passes an argument, which is received by the inner function as parameter we call name:


getRule :
function(name) {

return rules[name];
}

First, note that the return {} is written in object notation, therefore making getRule a local variable and, thus, private function only accessible through the namespace of Validation().

Validation() declares the rules local variable and because of the closure, we can access the rules local variable through the getRule() inner function.

*****Here's the part that really thows me off. We return rules[name]. So let's say name is equal to email. This is an associative array so email (held in name) is a property of rules. So here we return the object's property:


return rules[name];

And then assign it to a local variable called rule:


var rule = $.Validation.getRule(types[type]);

So when we return an object rules[name], do we return a reference to an object or a value? In other words, by returning rules[name], where name is equal to email, are we then returning a reference to the following object literal:


email : {
check: function(value) {

if(value)
return testPattern(value,".+@.+\..+");
return true;
},
msg : "Enter a valid e-mail address."
}

And if we are returning a reference, by returning a reference, are we essentially pointing to this object when we assign it to rule? In other words, the variable rule is just pointing to the object literal?

And is that the reason we can then access the check function or msg local variable through rule using dot notation, because rule points to the email object literal?

Now the ultimate brain twist for me is that if a function is an object, then why when return a function, it returns a value, such as a boolean, if an object only returns a reference and not the value?



//Validation is a local variable as it is in a self-executing anonymous function. The purpose of the said anonymous function is to pass the jQuery object as a parameter $ so the $() function will be in scope of the anonymous function and not interfere with other libraries that make use of the same function technique - in the global scope.
(function($) {
var rules = {

email : {
check: function(value) {

if(value)
return testPattern(value,".+@.+\..+");
return true;
},
msg : "Enter a valid e-mail address."
},
url : {

check : function(value) {

if(value)
return testPattern(value,"https?://(.+\.)+.{2,4}(/.*)?");
return true;
},
msg : "Enter a valid URL."
},
required : {

check: function(value) {

if(value)
return true;
else
return false;
},
msg : "This field is required."
}
}
var testPattern = function(value, pattern) {

var regExp = new RegExp("^"+pattern+"$","");
return regExp.test(value); //The test() method is built into javascript
}
return {

addRule : function(name, rule) {

rules[name] = rule;
},
getRule : function(name) {

return rules[name];
}
}
}

/*
Form factory
*/
var Form = function(form) {

var fields = [];

$(form[0].elements).each(function() {
var field = $(this);
if(field.attr('validation') !== undefined) {
fields.push(new Field(field));
}
});
this.fields = fields;
}
Form.prototype = {
validate : function() {

for(field in this.fields) {

this.fields[field].validate();
}
},
isValid : function() {

for(field in this.fields) {

if(!this.fields[field].valid) {

this.fields[field].field.focus();
return false;
}
}
return true;
}
}

/*
Field factory
*/
var Field = function(field) {

this.field = field;
this.valid = false;
this.attach("change");
}
Field.prototype = {

attach : function(event) {

var obj = this;
if(event == "change") {
obj.field.bind("change",function() {
return obj.validate();
});
}
if(event == "keyup") {
obj.field.bind("keyup",function(e) {
return obj.validate();
});
}
},
validate : function() {

var obj = this,
field = obj.field,
errorClass = "errorlist",
errorlist = $(document.createElement("ul")).addClass(errorClass),
types = field.attr("validation").split(" "),
container = field.parent(),
errors = [];

field.next(".errorlist").remove();
for (var type in types) {

var rule = $.Validation.getRule(types[type]);
if(!rule.check(field.val())) {

container.addClass("error");
errors.push(rule.msg);
}
}
if(errors.length) {

obj.field.unbind("keyup")
obj.attach("keyup");
field.after(errorlist.empty());
for(error in errors) {

errorlist.append("<li>"+ errors[error] +"</li>");
}
obj.valid = false;
}
else {
errorlist.remove();
container.removeClass("error");
obj.valid = true;
}
}
}

/*
Validation extends jQuery prototype
*/
$.extend($.fn, {

validation : function() {

var validator = new Form($(this));
$.data($(this)[0], 'validator', validator);

$(this).bind("submit", function(e) {
validator.validate();
if(!validator.isValid()) {
e.preventDefault();
}
});
},
validate : function() {

var validator = $.data($(this)[0], 'validator');
validator.validate();
return validator.isValid();

}
});
$.Validation = new Validation();
})(jQuery);



Thanks for any response.

Dormilich
08-24-2010, 02:23 PM
My confusion is compounded by the fact that I'm not sure if a function is an object or not.
According to the book JavaScript Programmer Reference it is:
"All functions in JavaScript are first class objects , meaning they can be passed around like any other object reference. In fact, regardless of how they are created, functions are instances of a global object named (aptly) Function."

However, someone else states that a function is not an object.

a function is an object. (period.) that someone probably didn’t understand the differences between class (e.g. Java) and prototype (e.g. Self) objects/inheritance.

in JavaScript there are 3 datatypes: primitives (undefined, null), literals (boolean/number/string literal, can be converted into the appropriate objects) & objects (everything else)

a function is insofar different, that it contains executeable code, which is called upon attaching () to the function name. if you just use the name, you handle it like every other variable. you can also extend the function and the Function object like any other object.

// extending the Function object, i.e. all functions
Function.prototype.sayHi = function ()
{
alert("Hi");
};
// create a "Function instance" (1 out of 3 ways)
function test()
{
alert(0);
}
// extend the variable test (which happens to be a function)
// to make it more confusing ... *g*
test.test = function ()
{
alert(1);
};
test(); // 0
test.test(); // 1
test.sayHi(); // Hi

PS. there is no "associative array" in JavaScript. such a construct is called: object.



So when we return an object rules[name], do we return a reference to an object or a value?
any object is passed by reference. any primitive/literal is passed by value.

johnmerlino
08-24-2010, 02:32 PM
So when we return an object rules[name], do we return a reference to an object or a value?

Dormilich
08-24-2010, 02:33 PM
see edit above

johnmerlino
08-24-2010, 02:55 PM
So this whole block becomes a reference:


email : {
check: function(value) {

if(value)
return testPattern(value,".+@.+\..+");
return true;
},
msg : "Enter a valid e-mail address."
}

Then that basically means if we change the value of msg after assigning the reference to a variable, all other variables that reference this object will in turn be updated to reflect the change of msg. Kind of like this I presume:


var myObj = {name:’David’, age:12};
var myObj2 = myObj;
myObj2.name = ‘Simon’;
document.write(myObj.name + “ < br / > ”); // “Simon”
document.write(myObj2.name + “ < br / > ”); // “Simon”

See how myObj name property changed when we changed myObj2 name property because myObj2 was pointing to the same reference. I presume the same thing happens in the example I gave. For example:


var rule = $.Validation.getRule(types[type]);
var rule2 = rule;
rule2.msg = 'reference change';
document.write(rule.msg); //'reference change'

If what I have above is correct, then I believe I understand what the return value is doing to an object.

Dormilich
08-24-2010, 03:00 PM
unfortunately, sometimes you want to pass objects as value (often with arrays), then you have to hard-copy them.

johnmerlino
08-30-2010, 08:02 PM
First, thanks for the response.

I see a lot where functions are returning objects using JavaScript Object Notation {} at the end of the function code block, with inner functions that are just simply declared in the object {}. What is the benefit of returning an object here. To create a closure? If that's the case, then why not just stick the return keyword in front of the two private functions, rather than putting the two private functions in an object and then returning the object? Or is it because by using the return keyword, it will only return the first object and break out of the function, never getting to the second private function?

Also, I thought the benefit of closures in javascript was that you make the parent scope the defining scope of the closure (the inner method), so that the variables declared in the parent scope are available to the inner method and no one else. Yet, isn't there scope chaining in javascript, where if a variable is not declared in a method, then it checks its parent scope, all the way until it reaches the global scope. So it appears that it will be checking the parent scope anyway, thus I don;t really see the added benefit of closures, unless there's some other benefit of closures.

Thanks for response.

DaveyErwin
08-30-2010, 09:25 PM
in javascript everything is an object
object properties are objects
string literals are objects
alert("hiyas".substring(0,1))
everything is an object

Dormilich
08-31-2010, 07:54 AM
in javascript everything is an object
except null and undefined


string literals are objects
alert("hiyas".substring(0,1))
counter proof:

// every JavaScript object inherits from the Object object
alert("hiyas" instanceof Object);
the literals may be converted to objects, but they ain’t objects.


everything is an object
simply wrong

DaveyErwin
08-31-2010, 09:36 AM
how would you go about converting
literal to object, you can see from

alert("hiyas".substring instanceof Object);

that "hiyas" is already an object,
no conversion necessary

when you do this ..
alert("hiyas" instanceof Object);
the object "hiyas" yeilds its value
so you are not checking the object

simply simple

you said...
the literals may be converted to objects, but they ain’t objects.

but that is backwords
a correct statement would be
literals are objects which may return a value
but they are always objects

rnd me
08-31-2010, 09:33 PM
you said...
the literals may be converted to objects, but they ain’t objects.

but that is backwords
a correct statement would be
literals are objects which may return a value
but they are always objects

no, literals are not objects. When you request a property of a literal, it is converted to an Object immediately before the property is accessed. The spec is quite clear on this.

DaveyErwin
08-31-2010, 11:08 PM
no, literals are not objects. When you request a property of a literal, it is converted to an Object immediately before the property is accessed. The spec is quite clear on this.

Quote that spec please.
Also the specs are not implimintation.
It is always an object .
Explain the process of conversion.

Dormilich
08-31-2010, 11:47 PM
@rnd_me: I doubt you can convince him (I failed too)

@DaveyErwin: see ECMAScript Language Specification 3rd Edition, sections 4.3.2 & 4.3.3 (type conversion is discussed in section 9)

DaveyErwin
09-01-2010, 01:47 AM
@rnd_me: I doubt you can convince him (I failed too)

@DaveyErwin: see ECMAScript Language Specification 3rd Edition, sections 4.3.2 & 4.3.3 (type conversion is discussed in section 9)

Thank You for the links.

johnmerlino
09-01-2010, 02:57 AM
So if scope chaining is built into javascript (variable checks parent scope if not defined in current scope), then what's the added benefit of closures? Someone said that the benefit of closures is when interpreter exits parent function (e.g. Validation()), you can call the inner function later (e.g. $.Validation.getRule()) and gain access to the variables of the parent. Yet, in scope chaining, that happens anyway! So I absolutely see no benefit in closures.

DaveyErwin
09-01-2010, 03:07 AM
So if scope chaining is built into javascript (variable checks parent scope if not defined in current scope), then what's the added benefit of closures? Someone said that the benefit of closures is when interpreter exits parent function (e.g. Validation()), you can call the inner function later (e.g. $.Validation.getRule()) and gain access to the variables of the parent. Yet, in scope chaining, that happens anyway! So I absolutely see no benefit in closures.

I don't know if your talkin to me ?
But just look at the code i posted
for the very simple count down timer,
thats all about closures.

DaveyErwin
09-01-2010, 04:18 AM
I am confused about what the return keyword is actually returning when returning an object, a primitive, or a function.

My confusion is compounded by the fact that I'm not sure if a function is an object or not.
According to the book JavaScript Programmer Reference it is:
"All functions in JavaScript are first class objects , meaning they can be passed around like any other object reference. In fact, regardless of how they are created, functions are instances of a global object named (aptly) Function."

However, someone else states that a function is not an object. An object is a set of primitives and references. A function is executable code. Functions become objects through the use of the new operator. Yet, in the book I mentioned, it says you don't need the new keyword to execute the function as an object, as it already inherits from the object Function when the function keyword is used:


function functionName([argname1 [, ...[, argnameN]]])
{
statements;
}

So there's one source of contradiction.

Now the bigger issue is what is going on when the return keyword is used. Notice the Validation() function returns an object as its last expression. This technique is common, where you return an object which contains functions in form of object notation. I believe this is done so that we create a closure so that when the intepreter exits the Validation() method, since we created a closure by returning an object, which contains the inner functions addRule and getRule, the local variables of Validation() are not destroyed, given that we can reference them through the two inner functions that make use of the local variables of the outer function. So when we use the return keyword on an object literal, and then exit the function, when we call one of the inner functions as we do later:


var rule = $.Validation.getRule(types[type]);

essentially getRule() is called, passes an argument, which is received by the inner function as parameter we call name:


getRule :
function(name) {

return rules[name];
}

First, note that the return {} is written in object notation, therefore making getRule a local variable and, thus, private function only accessible through the namespace of Validation().

Validation() declares the rules local variable and because of the closure, we can access the rules local variable through the getRule() inner function.

*****Here's the part that really thows me off. We return rules[name]. So let's say name is equal to email. This is an associative array so email (held in name) is a property of rules. So here we return the object's property:


return rules[name];

And then assign it to a local variable called rule:


var rule = $.Validation.getRule(types[type]);

So when we return an object rules[name], do we return a reference to an object or a value? In other words, by returning rules[name], where name is equal to email, are we then returning a reference to the following object literal:


email : {
check: function(value) {

if(value)
return testPattern(value,".+@.+\..+");
return true;
},
msg : "Enter a valid e-mail address."
}

And if we are returning a reference, by returning a reference, are we essentially pointing to this object when we assign it to rule? In other words, the variable rule is just pointing to the object literal?

And is that the reason we can then access the check function or msg local variable through rule using dot notation, because rule points to the email object literal?

Now the ultimate brain twist for me is that if a function is an object, then why when return a function, it returns a value, such as a boolean, if an object only returns a reference and not the value?



//Validation is a local variable as it is in a self-executing anonymous function. The purpose of the said anonymous function is to pass the jQuery object as a parameter $ so the $() function will be in scope of the anonymous function and not interfere with other libraries that make use of the same function technique - in the global scope.
(function($) {
var rules = {

email : {
check: function(value) {

if(value)
return testPattern(value,".+@.+\..+");
return true;
},
msg : "Enter a valid e-mail address."
},
url : {

check : function(value) {

if(value)
return testPattern(value,"https?://(.+\.)+.{2,4}(/.*)?");
return true;
},
msg : "Enter a valid URL."
},
required : {

check: function(value) {

if(value)
return true;
else
return false;
},
msg : "This field is required."
}
}
var testPattern = function(value, pattern) {

var regExp = new RegExp("^"+pattern+"$","");
return regExp.test(value); //The test() method is built into javascript
}
return {

addRule : function(name, rule) {

rules[name] = rule;
},
getRule : function(name) {

return rules[name];
}
}
}

/*
Form factory
*/
var Form = function(form) {

var fields = [];

$(form[0].elements).each(function() {
var field = $(this);
if(field.attr('validation') !== undefined) {
fields.push(new Field(field));
}
});
this.fields = fields;
}
Form.prototype = {
validate : function() {

for(field in this.fields) {

this.fields[field].validate();
}
},
isValid : function() {

for(field in this.fields) {

if(!this.fields[field].valid) {

this.fields[field].field.focus();
return false;
}
}
return true;
}
}

/*
Field factory
*/
var Field = function(field) {

this.field = field;
this.valid = false;
this.attach("change");
}
Field.prototype = {

attach : function(event) {

var obj = this;
if(event == "change") {
obj.field.bind("change",function() {
return obj.validate();
});
}
if(event == "keyup") {
obj.field.bind("keyup",function(e) {
return obj.validate();
});
}
},
validate : function() {

var obj = this,
field = obj.field,
errorClass = "errorlist",
errorlist = $(document.createElement("ul")).addClass(errorClass),
types = field.attr("validation").split(" "),
container = field.parent(),
errors = [];

field.next(".errorlist").remove();
for (var type in types) {

var rule = $.Validation.getRule(types[type]);
if(!rule.check(field.val())) {

container.addClass("error");
errors.push(rule.msg);
}
}
if(errors.length) {

obj.field.unbind("keyup")
obj.attach("keyup");
field.after(errorlist.empty());
for(error in errors) {

errorlist.append("<li>"+ errors[error] +"</li>");
}
obj.valid = false;
}
else {
errorlist.remove();
container.removeClass("error");
obj.valid = true;
}
}
}

/*
Validation extends jQuery prototype
*/
$.extend($.fn, {

validation : function() {

var validator = new Form($(this));
$.data($(this)[0], 'validator', validator);

$(this).bind("submit", function(e) {
validator.validate();
if(!validator.isValid()) {
e.preventDefault();
}
});
},
validate : function() {

var validator = $.data($(this)[0], 'validator');
validator.validate();
return validator.isValid();

}
});
$.Validation = new Validation();
})(jQuery);



Thanks for any response.

It returns an Object , don't forget my thanks....uh

Dormilich
09-01-2010, 09:33 AM
you’re misunderstanding closures. a closure not only has access to its inner and outer variables, it also preserves them over the usual lifetime. (basically having acces to variables that would normally have been destroyed)



Function.prototype.bind = function (obj) {
var fn = this;
return function () {
return fn.apply(obj, arguments);
}
};

without the closure, the variable fn would be destroyed after calling (local variables exist only while the function is called). due to the closure, JS "remembers" (keeps in memory) the value of fn (in this case a reference to a said function object)


It returns an Object , don't forget my thanks....uh
lol

DaveyErwin
09-01-2010, 12:42 PM
you’re misunderstanding closures. a closure not only has access to its inner and outer variables, it also preserves them over the usual lifetime. (basically having acces to variables that would normally have been destroyed)



Function.prototype.bind = function (obj) {
var fn = this;
return function () {
return fn.apply(obj, arguments);
}
};

without the closure, the variable fn would be destroyed after calling (local variables exist only while the function is called). due to the closure, JS "remembers" (keeps in memory) the value of fn (in this case a reference to a said function object)


lol

can you be specific about what i have misunderstood.
i beleve you are deeply mistaken.

Dormilich
09-01-2010, 05:05 PM
can you be specific about what i have misunderstood.
i beleve you are deeply mistaken.

this was the answer to post #15. it’s not directly related to your post above it.

DaveyErwin
09-01-2010, 06:16 PM
this was the answer to post #15. it’s not directly related to your post above it.

Sorry, myBad.
Overly defensive by nature.

rnd me
09-01-2010, 08:03 PM
Quote that spec please.
Also the specs are not implimintation.
It is always an object .
Explain the process of conversion.


all implementations follow the spec (more or less), that's why they are interoperable.


// ALL true:
typeof "wrong" === "string";
typeof 7734 === "number";
typeof "wrong".bold() === "string";

check yourself before you wreck yourself.

DaveyErwin
09-01-2010, 09:00 PM
all implementations follow the spec (more or less), that's why they are interoperable.


// ALL true:
typeof "wrong" === "string";
typeof 7734 === "number";
typeof "wrong".bold() === "string";

check yourself before you wreck yourself.

The string is an object that has the ability to
reveal its self as a string . It is always an object.

Old Pedant
09-01-2010, 09:02 PM
Give it up, RndMe. He won't read the specifications. He thinks he knows the answers without reading them.

DaveyErwin
09-01-2010, 09:20 PM
Give it up, RndMe. He won't read the specifications. He thinks he knows the answers without reading them.

Please quote the relevant text.

Old Pedant
09-01-2010, 09:44 PM
http://interglacial.com/javascript_spec/a-4.html#a-4.3.2

That's exactly what it says in the PDF doc on the official ECMA site, but in HTML form so easy to refer to.

Also 4.3.9, 4.3.11, 4.3.13, 4.3.16, 4.3.19

Note the distinctions that are *CAREFULLY* made between type and object. For example, 4.3.17 vs. 4.3.18 and 4.3.20 vs. 4.3.21.

See also chapters 8 and 9.

DaveyErwin
09-01-2010, 10:18 PM
http://interglacial.com/javascript_spec/a-4.html#a-4.3.2

That's exactly what it says in the PDF doc on the official ECMA site, but in HTML form so easy to refer to.

Also 4.3.9, 4.3.11, 4.3.13, 4.3.16, 4.3.19

Note the distinctions that are *CAREFULLY* made between type and object. For example, 4.3.17 vs. 4.3.18 and 4.3.20 vs. 4.3.21.

See also chapters 8 and 9.

Could you please quote the relevant text?

Old Pedant
09-01-2010, 10:31 PM
No. That paragraph is two short sentences long. It's all relevant. Read it.

I'm not continuing this thread.

DaveyErwin
09-01-2010, 10:33 PM
no. That paragraph is two short sentences long. It's all relevant. Read it.

I'm not continuing this thread.

:( :(

gmatrix21
09-01-2010, 10:41 PM
We treat our advertisers and publishers not only as business partners but also as family. We deliver the highest ROI and have a strong management team to meet both our advertisers and publishers needs to grow both their businesses.

http://www.globalmatrixmedia.com/

rnd me
09-01-2010, 11:56 PM
The string is an object that has the ability to
reveal its self as a string . It is always an object.

ok, explain how these experiments confirm your theory:


var prim="dan";
var obj= new String("dan");
alert( prim === obj ); //false



var prim2="dan";
var obj2= "dan";
alert(prim2===obj2); //true

DaveyErwin
09-02-2010, 12:10 AM
ok, explain how these experiments confirm your theory:


var prim="dan";
var obj= new String("dan");
alert( prim === obj ); //false



var prim2="dan";
var obj2= "dan";
alert(prim2===obj2); //true

The false is because they are different objects
The true is because prim2 and obj2 are refferencing the same object

Thanks for providing proof for my position.

DaveyErwin
09-02-2010, 12:32 AM
LOL!!! See, I *told* you, RndMe. He is *NOT* going to be convinced!

I love it.

Well the code he posted has convinced me that everything is an object in javascript.


No. That paragraph is two short sentences long. It's all relevant. Read it.

I'm not continuing this thread.

Dormilich
09-02-2010, 12:43 AM
Well the code he posted has convinced me that everything is an object in javascript.

that finally convinces me that you have no idea of object or JavaScript object handling.

DaveyErwin
09-02-2010, 01:00 AM
No need to get snipitty.
Would you be inclined to elaborate on object handling?

Dormilich
09-02-2010, 01:36 AM
there’s no point in doing that. you wouldn’t understand anyway.

DaveyErwin
09-02-2010, 02:21 AM
there’s no point in doing that. you wouldn’t understand anyway.

Possibly you will enumerate this thinds ?

rnd me
09-02-2010, 08:13 PM
The true is because prim2 and obj2 are refferencing the same object

Thanks for providing proof for my position.


var prim2="dan";
var obj2= "dan";

prim2.dan="fred";
alert(prim2.dan)


how do you know are prim2 and obj2 are really the same object?
also, why won't the prim2 object accept the dan property (like all other objects do)?

here is a real string object, notice how it behaves:

var obj=new String("dan");
obj.dan="fred";

alert(obj.dan)

not sure why you are so adamantly ignorant.
personally, when i have several senior coders all telling me the same thing i tend to listen or at least read the links they post.

DaveyErwin
09-02-2010, 08:31 PM
var prim2="dan";
var obj2= "dan";

prim2.dan="fred";
alert(prim2.dan)

how do you know are prim2 and obj2 the same object?



Because ...


var prim2="dan";
var obj2= "dan";
alert(prim2===obj2); //true



also, why won't the prim2 object accept the dan property (like all other objects do)?


I can't get what accept is ?
You don't seem to be very good at asking questions.



here is a real string object, notice how it behaves:

var obj=new String("dan");
obj.dan="fred";

alert(obj.dan)



Yes, I am very aware of how objects behave,
but i would like some commentary on object handling.

rnd me
09-02-2010, 10:32 PM
var prim2="dan";
var obj2= "dan";
alert(prim2===obj2); //true

I can't get what accept is ?
You don't seem to be very good at asking questions.

you're even worse at answering them ;)
I'm asking why does the alert show "undefined" when asking for the "dan" property of prim2 in the following code:


var prim2="dan";
var obj2= "dan";

prim2.dan="fred";
alert(prim2.dan); //shows undefined

All objects (except null) can store properties.
prim2 cannot store a property.
therefore, prim2 is not an object.



furthermore,
since objects are assessed by reference,
if prim2 and obj2 are the same object
altering one would alter the other:


var prim2="dan";
var obj2= "dan";

prim2+=" more text";
alert(prim2===obj2);//false

altering prim2 had no effect on obj2.
therefore, prim2 or obj2 (or both) are not objects.

what is your specific question about object handling?

Old Pedant
09-02-2010, 11:02 PM
I know I'm going to regret this...

Even more clearly than *this* failing:


var prim2="dan";
prim2.dan="fred";

would be this:


"dan".whatever = "fred";

If a literal string is an object, that should work. Clearly it doesn't. Clearly a literal string is not an object.

You have MUCH more patience than I do, RndMe.

DaveyErwin
09-02-2010, 11:34 PM
All objects (except null) can store properties.


You are getting very close now.


a = null;
alert(a == 'null');
alert(null)
alert(a)

DaveyErwin
09-02-2010, 11:39 PM
I know I'm going to regret this...







I'm not continuing this thread.

:p:p:p

Dormilich
09-03-2010, 12:13 AM
a = null;
alert(a == 'null');
alert(null)
alert(a)

what should that prove?

DaveyErwin
09-03-2010, 12:16 AM
what should that prove?

Does it say any thing at all to you ?

Dormilich
09-03-2010, 12:44 AM
only that null !== "null", but I already knew that.



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum