They create exactly the same result.
The object or array literal is likely to be a tiny bit faster than the new
Object/Array, because it avoids a name lookup (or several name lookups if
you're inside a nested function). But of course even if it is faster, it
would make a difference only if you're doing a large number of them.
One advantage of the object/array notations is that they let you simplify
the code even further. You can write this:
var datascape = {
el: $('#datascape'),
ini: function(){
datascape.el.click(function(){
dothis();
dothat();
});
}
}
Instead of:
var datascape = new Object();
datascape.el = $('#datascape');
datascape.ini = function(){
datascape.el.click(function(){
dothis();
dothat();
});
}
Here, the object literal saves even more name lookups (the datascape
references) and is shorter and more convenient too.
BTW, note that there's a semicolon missing in this code:
datascape.ini = function(){
datascape.el.click(function(){
dothis();
dothat();
});
}; // <-- semicolon required here
Because of JavaScript's semicolon insertion, you can often get away without
it, but not always - so get in the habit of putting the semicolon in.
A function declaration does not require a semicolon at the end:
function foo() {}
But an assignment statement using a function expression, just like any other
assignment statement, does require it:
foo = function() {};
-Mike
> From: Alexandre Plennevaux
>
> why? It's just a shorthand, isn't it ? does it affect the
> computer resources in any manner ?
>
> On Wed, Dec 31, 2008 at 3:12 AM, Kean <shenan...@gmail.com> wrote:
> >
> > Just a nitpick.
> >
> > Don't do this
> > var datascape = new Object();
> > var datascape2 = new Array();
> >
> > Instead
> > var datascape = {};
> > var datascape2 = [];
> >
> >
> > On Dec 30, 1:27 pm, "Alexandre Plennevaux" <aplennev...@gmail.com>
> > wrote:
> >> wair, you're all scarrying me:
> >>
> >> i often do things like this:
> >>
> >> var datascape = new Object();
> >>
> >> datascape.el = $('#datascape');
> >> datascape.ini = function(){
> >> datascape.el.click(function(){
> >> dothis();
> >> dothat();
> >> });
> >>
> >> }
> >>
> >> is this pattern causing a potential memory leak problem,
> because the
> >> js object is linked to a DOM element?
> >>
> >> On Tue, Dec 30, 2008 at 10:10 PM, Kean <shenan...@gmail.com> wrote:
> >>
> >> > A good reason why closure is used
> >>
> >> >http://yuiblog.com/blog/2006/06/01/global-domination/
> >>
> >> > On Dec 30, 1:04 pm, Kean <shenan...@gmail.com> wrote:
> >> >> Klaus is right,
> >>
> >> >> Here's an article about closure causing
> >> >>
> leakshttp://www.javascriptkit.com/javatutors/closuresleak/index.sh
> >> >> tml
> >>
> >> >> On Dec 30, 4:38 am, "Alexandre Plennevaux"
> <aplennev...@gmail.com>
> >> >> wrote:
> >>
> >> >> > Klaus, you got me: frankly i have no "real" idea what is the
> >> >> > purpose of enclosure.
> >> >> > That's abstract art to me. i just read in several places that
> >> >> > it's good to use it, so i trust my sources, do it and
> move on.
> >> >> > Not that i'm proud of it, but, to use a metaphor, one
> does not
> >> >> > need to know the internals of a car in order to be
> able to drive
> >> >> > it, although it surely is a valuable knowledge if one
> wants to keep its car in a good state !
> >> >> > Yet, since the car changes every six months, it's just up to
> >> >> > you, wheather you're driven by the pure developer's
> passion or
> >> >> > by consumer pragmatism.
> >>
> >> >> > On Tue, Dec 30, 2008 at 1:28 PM, Klaus Hartl
> <klaus.ha...@googlemail.com> wrote:
> >>
> >> >> > > On 30 Dez., 08:45, "Alexandre Plennevaux"
> >> >> > > <aplennev...@gmail.com>
> >> >> > > wrote:
> >> >> > >> "JavaScript enclosures"?
> >>
> >> >> > >> i think it has to do with encapsulating your code inside a
> >> >> > >> function so that all vars are inside the
> function's scope, so
> >> >> > >> not cluttering the global namespace.
> >> >> > >> This, to avoid memory leak.
> >>
> >> >> > > Are you implying that global variables do leak
> memory? There
> >> >> > > are good reasons to not clutter the global namespace but I
> >> >> > > don't believe avoiding leaks is one of them.
> >>
> >> >> > > Actually you do increase the chance to create leaks
> in IE if
> >> >> > > you use closures under certain circumstances.
> >>
> >> >> > > --Klaus
>
