return keyword applied on object returns reference or value?
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:
Code:
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:
Code:
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:
Code:
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:
Code:
return rules[name];
And then assign it to a local variable called rule:
Code:
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:
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?
Code:
//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);
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.
PHP Code:
// 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.
Edit:
Quote:
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.
__________________
please post your code wrapped in [CODE] [/CODE] tags
Last edited by Dormilich; 08-24-2010 at 02:39 PM..
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:
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:
Code:
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.
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.
Last edited by johnmerlino; 08-30-2010 at 09:20 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.
__________________ my site (updated 5/13) STATS (2013/5) HTML5:90.2% MOB:14% IE7:0.5% IE8:8.6% IE9:9.8% IE10:10%
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.
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.
Before you post, read our: 
