Scope of result of new

[André Hänsel]

Hi,

I am using ExtJS but this should make no difference. I am wondering
why this:

function init() {
var w = {};
w = new Ext.Window({
items: {
keys:{
key: Ext.EventObject.ENTER,
fn: function(){ this.save(); },
scope: w
},
},
save: function()
{
console.log('save');
}
});
}

is different from this:

function init() {
var test;
var w = new Ext.Window({
items: {
keys:{
key: Ext.EventObject.ENTER,
fn: function(){ this.save(); },
scope: test
},
},
save: function()
{
console.log('save');
}
});
test = w;
}

In the first example the scope of the innermost anonymous function (w)
is the empty object while in the second example it's the Ext.Window
object.

Aren't w and test in the same scope? So the additional assignment
shouldn't be necessary, should it?

Regards,
André

 

[Lasse Reichstein Nielsen]

I am wondering why this:

function init() {
var w = {};
w = new Ext.Window({
items: {
keys:{
key: Ext.EventObject.ENTER,
fn: function(){ this.save(); },
scope: w

At this point w references the empty object it was assigned above.

},
},
save: function()
{
console.log('save');
}
});
}

is different from this:

function init() {
var test;
var w = new Ext.Window({
items: {
keys:{
key: Ext.EventObject.ENTER,
fn: function(){ this.save(); },
scope: test

At this point, test has the value "undefined", since it hasn't been
assigned a value yet.

},
},
save: function()
{
console.log('save');
}
});
test = w;
}

In the first example the scope of the innermost anonymous function (w)
is the empty object while in the second example it's the Ext.Window
object.

Are you sure. It looks like it should be undefined.
Or maybe Ext.js does picks a default if the value is undefined (it does
matter what Ext.Window does with the arguments).

Aren't w and test in the same scope?
Yes.

So the additional assignment shouldn't be necessary, should it?

The last assignment to test is a complete no-op. The test variable
goes out of scope immediately after.

Remember that the values of the object literals are evaluated at
object creation time. Assigning to test after that makes no difference
at all.

/L

 

[André Hänsel]

Are you sure.

No, unfortunately I'm not. Sorry, when setting up a testcase I found
out, that none of the both ways works. I must have seen something
wrong.

What stays is the question, how I get a reference to the Ext.Window
object into that anonymous function, but I guess that's more of an
ExtJS question.

Regards,
André

 

[André Hänsel]

It can be so easy...

function init() {
w = new Ext.Window({
items: {
keys:{
key: Ext.EventObject.ENTER,
fn: function(){ w.save(); },
},
},
save: function()
{
console.log('save');
}
});
}

 

[Thomas 'PointedEars' Lahn]

It can be so easy...

function init() {
w = new Ext.Window({
items: {
keys:{
key: Ext.EventObject.ENTER,
fn: function(){ w.save(); },
},
},
save: function()
{
console.log('save');
}
});
}

You did declare `w', didn't you? And you really should eschew ExtJS, it's
proven junk.


PointedEars

 

[Sean Kinsey]

On May 19, 1:57 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
....

You did declare `w', didn't you?  And you really should eschew ExtJS, it's
proven junk.

If so then its junk that works, and that saves you a helluvalot of
time.
The library might have some issues (like most complex libaries) but I
can easily work around those within the time I save doing everything
else.

 

[David Mark]

On May 19, 1:57 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
...

If so then its junk that works, and that saves you a helluvalot of
time.

Junk that relies on browser sniffing cannot possibly save you time in
the long run. Think about it. If it is written based on today's
observations, then what happens tomorrow? It's programming for failure.

The library might have some issues (like most complex libaries) but I
can easily work around those within the time I save doing everything
else.

Does it ever have issues. And your workarounds may well conflict
with whatever Ext releases next month. They are known to break
compatibility often enough on their own and you are compounding that
problem with monkey patching.

You haven't really thought this through at all, have you? Don't be
hypnotized by pretty widgets.

 

[Sean Kinsey]

Does it ever have issues.    And your workarounds may well conflict
with whatever Ext releases next month.  They are known to break
compatibility often enough on their own and you are compounding that
problem with monkey patching.

You haven't really thought this through at all, have you?  Don't be
hypnotized by pretty widgets.

Ah, thats actually one of the first things I've laughed at all day

No, but seriously - even if I decided to replace all the checks
for .isIE (there are 86 of them in in ext-all-debug.js) then I would
probably still use less time on this than on creating all the widgets
manually, or say, by using My Library.
And there's no need to remind me that there is also .isOpera etc..

Instead of spewing out the same ill-crafted arguments each time
someone mentions x, y or z, why don't you do like most other and write
a Good Blog Post (tm) about it? Can't you just see it? It would spread
like wild fire, you could be the one who saves the internet!

 

[David Mark]

Ah, thats actually one of the first things I've laughed at all day

Laughter is the best medicine.

No, but seriously - even if I decided to replace all the checks
for .isIE (there are 86 of them in in ext-all-debug.js)

LOL. 86 huh? What would you replace them with? And see my recent post
about IE9.

then I would
probably still use less time on this than on creating all the widgets
manually, or say, by using My Library.

My Library has a nice array of widgets (and more are on the way). See
the Examples page. There's no such thing as a widget that should take
more than a day or two to write for My Library. And they last virtually
forever (as evidenced by their compatibility with the last ten year's
worth of browsers).

And there's no need to remind me that there is also .isOpera etc..

Yes, I'm sure it's quite a snarl. So anything you write today is
instantly dated.

Instead of spewing out the same ill-crafted arguments each time
someone mentions x, y or z, why don't you do like most other and write
a Good Blog Post (tm) about it?

What part of my arguments did you find ill-crafted?

Can't you just see it? It would spread
like wild fire, you could be the one who saves the internet!

I've already done more than you can imagine in that area. I don't
typically write the blog posts though (I leave that to others).

http://www.cinsoft.net/host.html