Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 4 123 ... LastLast
Results 1 to 15 of 46
  1. #1
    Regular Coder
    Join Date
    Oct 2009
    Posts
    189
    Thanks
    38
    Thanked 3 Times in 3 Posts

    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:
    Code:
    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?

    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);
    Thanks for any response.

  • #2
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,253
    Thanks
    12
    Thanked 341 Times in 337 Posts
    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:
    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.
    Last edited by Dormilich; 08-24-2010 at 02:39 PM.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #3
    Regular Coder
    Join Date
    Oct 2009
    Posts
    189
    Thanks
    38
    Thanked 3 Times in 3 Posts
    So when we return an object rules[name], do we return a reference to an object or a value?

  • #4
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,253
    Thanks
    12
    Thanked 341 Times in 337 Posts
    see edit above
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #5
    Regular Coder
    Join Date
    Oct 2009
    Posts
    189
    Thanks
    38
    Thanked 3 Times in 3 Posts
    So this whole block becomes a reference:
    Code:
    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:
    Code:
    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:
    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.

  • #6
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,253
    Thanks
    12
    Thanked 341 Times in 337 Posts
    unfortunately, sometimes you want to pass objects as value (often with arrays), then you have to hard-copy them.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #7
    Regular Coder
    Join Date
    Oct 2009
    Posts
    189
    Thanks
    38
    Thanked 3 Times in 3 Posts
    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.
    Last edited by johnmerlino; 08-30-2010 at 09:20 PM.

  • #8
    Regular Coder
    Join Date
    Aug 2010
    Posts
    967
    Thanks
    19
    Thanked 211 Times in 209 Posts
    in javascript everything is an object
    object properties are objects
    string literals are objects
    alert("hiyas".substring(0,1))
    everything is an object

  • #9
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,253
    Thanks
    12
    Thanked 341 Times in 337 Posts
    Quote Originally Posted by DaveyErwin View Post
    in javascript everything is an object
    except null and undefined

    Quote Originally Posted by DaveyErwin View Post
    string literals are objects
    alert("hiyas".substring(0,1))
    counter proof:
    Code:
    // every JavaScript object inherits from the Object object
    alert("hiyas" instanceof Object);
    the literals may be converted to objects, but they ain’t objects.

    Quote Originally Posted by DaveyErwin View Post
    everything is an object
    simply wrong
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #10
    Regular Coder
    Join Date
    Aug 2010
    Posts
    967
    Thanks
    19
    Thanked 211 Times in 209 Posts
    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
    Last edited by DaveyErwin; 08-31-2010 at 11:26 AM.

  • #11
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,297
    Thanks
    10
    Thanked 584 Times in 565 Posts
    Quote Originally Posted by DaveyErwin View Post

    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 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #12
    Regular Coder
    Join Date
    Aug 2010
    Posts
    967
    Thanks
    19
    Thanked 211 Times in 209 Posts
    Quote Originally Posted by rnd me View Post
    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.

  • #13
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,253
    Thanks
    12
    Thanked 341 Times in 337 Posts
    @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)
    Last edited by Dormilich; 08-31-2010 at 11:54 PM.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • Users who have thanked Dormilich for this post:

    johnmerlino (09-01-2010)

  • #14
    Regular Coder
    Join Date
    Aug 2010
    Posts
    967
    Thanks
    19
    Thanked 211 Times in 209 Posts

    Unhappy

    Quote Originally Posted by Dormilich View Post
    @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.
    Last edited by DaveyErwin; 09-01-2010 at 01:50 AM.

  • #15
    Regular Coder
    Join Date
    Oct 2009
    Posts
    189
    Thanks
    38
    Thanked 3 Times in 3 Posts
    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.


  •  
    Page 1 of 4 123 ... LastLast

    Tags for this Thread

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •