Object Functions
While it is always best practice to never extend the ‘prototype’ of Object, it is fine to extend Object directly with your own static methods. There are 4 methods that I find critical to working with JavaScript objects: forEach, getIgnoreKeys, is, and toQueryString. The ‘forEach’ method iterates on the Object using the “for … in” loop, but calls ‘getIgnoreKeys’ to determine which keys are methods attached to the Object prototype, and ignores those values. You can also use the ‘forEach’ method to iterate on an Array, even though it would be more efficient to use the ‘forEach’ method we attached to Array in my last post. Lastly, the ‘is’ Function is simply a type detection method and ‘toQueryString’ calls ‘forEach’ so that we can construct a query string, “key1=value1&key2=value2&key3=value3…”.
Check out object.js here and the unit test here.
Attaching a toQueryString method directly to Object seems fairly ad-hoc. If you consider serialization, only your imagination limits the amount of functions needed. query strings, json, xml, you name it.
It’s also worth noting that the serialization only makes sense when the Object instances are used as hash maps (or in your case, they are hash maps and only have ONE level). Unfortunately I’ve made the same mistake myself
I’ll move them all to a new “Util.Hash” package when I get the time.
Comment by Adam — July 26, 2008 @ 2:17 pm
There is no use of “this” in your code so why attach these function-valued properties to “Object”? I think you would be better to just attach them to either the global object, or an object of your own. Attaching them to “Object” implies there is some reason to do so but I cannot think of one in this case or any case.
Comment by Peter Michaux — July 26, 2008 @ 4:48 pm
Adam, toQueryString, isn’t a perfect method, and is really only meant to work with key/value pairs of string or number objects.
Peter, actually I originally wrote these methods as static methods, but I moved them to Object, because that is where I logically expect them to be. However, they work just fine as static methods anywhere.
Comment by Matt Snider — July 26, 2008 @ 5:08 pm
If the user doesn’t send in a function into your forEach method, you simply create an emtpy function. Why not just exit the method? It seems a waste of time running a function that doesn’t actually do anything. I might go so far as to say don’t even check to see if it’s a function. As long as your code is well documented, and it is, then the user should know to send a function, or quickly find out through a thrown error.
I do understand why these are on the Object itself. It seems the logical place to put them. However, considering namespace issues that might appear, it probably is wisest to use your own global object.
Comment by MillsJROSS — July 28, 2008 @ 12:46 pm
MillsJROSS, good catch on the forEach method. I changed it so that if the parameter ‘fn’ is not a Function, then forEach simply returns, instead of iterating on the Array.
Comment by Matt Snider — July 30, 2008 @ 9:37 am