Is there a reason that isUndefined is structured the way it is, such
that an undefined variable/object will throw an error.

dojo.lang.isUndefined = function(wh){
return ((wh == undefined)&&(typeof wh == "undefined"));
}

if you do

dojo.lang.isUndefined(foo);

with no other reference to foo in your code it'll throw a JS error,
becuase JS doesn't like checking for objects that don't exist, rather
preferring you to checkf ro properties of existing objects.


so...

dojo.lang.isUndefined(window.foo);

will return False as expected.

I was just talking with Mr. Wiltshire about this, and one idea I had
was that if you did:

dojo.lang.isUndefined = function(wh){
return ((typeof wh == "undefined")||(wh == undefined));
}

That way actual real undefined objects will not fail, but will return
false as expected. My logic being that I assume we're testing for
two possible states, if the first in the above two is true it won't
even try to do the second one (which throws the error) because we're
using an OR, but if it doesn't it'll just check the second possible
undefined to cover bases.

Thoughts?

Should I log this on Trac somewhere?

I see that Alex has a trac at:

http://trac.dojotoolkit.org/changeset/1418

or should I add it to:

http://trac.dojotoolkit.org/changeset/2118



Jon Sykes

Search Discussions

  • Scott J. Miles at Jun 29, 2006 at 11:26 am
    Afaik, generally the exception happens as soon as 'foo' is evaluated, which
    occurs before any implementation of dojo.lang.isUndefined can execute.

    The reference named 'foo' itself has no relevance to bar when invoking
    bar(foo), only the *value* of foo has relevance. In particular,
    dojo.lang.isUndefined(undefined) correctly returns true.

    Using a global variable that may not exist (in any expression) requires
    window.foo or even dj_global.foo, possibly <context>["foo"] to support older
    IE.

    If you really wanted to extend isUndefined to do safe global checking you
    would need to allow calls like so:

    isUndefined("foo"); // maps to isUndefined(window["foo"])
    isUndefined("foo", obj); // maps to isUndefined(obj["foo"])

    Regards,
    Scott J. Miles
    TurboAjax Group
    http://www.turboajax.com

    -----Original Message-----
    From: dojo-contributors-bounces@dojotoolkit.org
    On Behalf Of Jon Sykes
    Sent: Thursday, June 29, 2006 8:08 AM
    To: dojo dev.
    Subject: [dojo-contributors] Re: dojo.lang.isUndefined()

    Is there a reason that isUndefined is structured the way it is, such that an
    undefined variable/object will throw an error.

    dojo.lang.isUndefined = function(wh){
    return ((wh == undefined)&&(typeof wh == "undefined")); }

    if you do

    dojo.lang.isUndefined(foo);

    with no other reference to foo in your code it'll throw a JS error, becuase
    JS doesn't like checking for objects that don't exist, rather preferring you
    to checkf ro properties of existing objects.


    so...

    dojo.lang.isUndefined(window.foo);

    will return False as expected.

    I was just talking with Mr. Wiltshire about this, and one idea I had was
    that if you did:

    dojo.lang.isUndefined = function(wh){
    return ((typeof wh == "undefined")||(wh == undefined)); }

    That way actual real undefined objects will not fail, but will return false
    as expected. My logic being that I assume we're testing for two possible
    states, if the first in the above two is true it won't even try to do the
    second one (which throws the error) because we're using an OR, but if it
    doesn't it'll just check the second possible undefined to cover bases.

    Thoughts?

    Should I log this on Trac somewhere?

    I see that Alex has a trac at:

    http://trac.dojotoolkit.org/changeset/1418

    or should I add it to:

    http://trac.dojotoolkit.org/changeset/2118



    Jon Sykes
  • Jon Sykes at Jun 29, 2006 at 11:36 am

    On Jun 29, 2006, at 1:26 PM, Scott J. Miles wrote:

    Afaik, generally the exception happens as soon as 'foo' is
    evaluated, which
    occurs before any implementation of dojo.lang.isUndefined can execute.
    Not sure I understand, if you put:

    if((wh == undefined)&&(typeof wh == "undefined"))alert("foo is
    undefined");

    in to the firebug console and hit enter, if you don't have foo set,
    it will fire the alert. Isn't that what isUndefined should do?
    The reference named 'foo' itself has no relevance to bar when invoking
    bar(foo), only the *value* of foo has relevance. In particular,
    dojo.lang.isUndefined(undefined) correctly returns true.
    Again, not sure I understand what you mean.
    Using a global variable that may not exist (in any expression)
    requires
    window.foo or even dj_global.foo, possibly <context>["foo"] to
    support older
    IE.
    How much older IE do we need to support?
    If you really wanted to extend isUndefined to do safe global
    checking you
    would need to allow calls like so:

    isUndefined("foo"); // maps to isUndefined(window["foo"])
    isUndefined("foo", obj); // maps to isUndefined(obj["foo"])
    Yup I can see that being an extension. But you would think that if
    you know what the parent obj is of the thing you want to check you
    could just do:

    isUndefined(obj.foo);



    Regards,
    Scott J. Miles
    TurboAjax Group
    http://www.turboajax.com

    -----Original Message-----
    From: dojo-contributors-bounces@dojotoolkit.org
    On Behalf Of Jon
    Sykes
    Sent: Thursday, June 29, 2006 8:08 AM
    To: dojo dev.
    Subject: [dojo-contributors] Re: dojo.lang.isUndefined()

    Is there a reason that isUndefined is structured the way it is,
    such that an
    undefined variable/object will throw an error.

    dojo.lang.isUndefined = function(wh){
    return ((wh == undefined)&&(typeof wh == "undefined")); }

    if you do

    dojo.lang.isUndefined(foo);

    with no other reference to foo in your code it'll throw a JS error,
    becuase
    JS doesn't like checking for objects that don't exist, rather
    preferring you
    to checkf ro properties of existing objects.


    so...

    dojo.lang.isUndefined(window.foo);

    will return False as expected.

    I was just talking with Mr. Wiltshire about this, and one idea I
    had was
    that if you did:

    dojo.lang.isUndefined = function(wh){
    return ((typeof wh == "undefined")||(wh == undefined)); }

    That way actual real undefined objects will not fail, but will
    return false
    as expected. My logic being that I assume we're testing for two
    possible
    states, if the first in the above two is true it won't even try to
    do the
    second one (which throws the error) because we're using an OR, but
    if it
    doesn't it'll just check the second possible undefined to cover bases.

    Thoughts?

    Should I log this on Trac somewhere?

    I see that Alex has a trac at:

    http://trac.dojotoolkit.org/changeset/1418

    or should I add it to:

    http://trac.dojotoolkit.org/changeset/2118



    Jon Sykes


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Scott J. Miles at Jun 29, 2006 at 12:30 pm
    I understood you to say that

    dojo.lang.isUndefined(foo);

    throws an exception if 'foo' has no prior definition, and that you wanted to
    change the implementation of isUndefined to resolve this problem.

    My position is that this has *nothing* to do with isUndefined. Any
    expression containing 'foo' will throw an exception. E.g.

    (function(){})(foo);
    alert(foo);

    All of this occurs when 'foo' is evaluated which happens *before* any code
    can be invoked on the evaluated value.
    Not sure I understand, if you put:
    if((wh == undefined)&&(typeof wh == "undefined"))alert("foo is undefined");

    in to the firebug console and hit enter, if you don't have foo set, it will
    fire the alert. Isn't that what isUndefined should do? <<

    It looks like you didn't paste what you meant to paste: your example doesn't
    reference 'foo' at all. Putting what you did paste into the console, an
    exception is thrown because 'wh' cannot be evaluated as an operand to '==',
    which is exactly my point.

    Regards,
    Scott J. Miles
    TurboAjax Group
    http://www.turboajax.com

    -----Original Message-----
    From: dojo-contributors-bounces@dojotoolkit.org
    On Behalf Of Jon Sykes
    Sent: Thursday, June 29, 2006 10:37 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Re: dojo.lang.isUndefined()

    On Jun 29, 2006, at 1:26 PM, Scott J. Miles wrote:

    Afaik, generally the exception happens as soon as 'foo' is evaluated,
    which occurs before any implementation of dojo.lang.isUndefined can
    execute.
    Not sure I understand, if you put:

    if((wh == undefined)&&(typeof wh == "undefined"))alert("foo is undefined");

    in to the firebug console and hit enter, if you don't have foo set, it will
    fire the alert. Isn't that what isUndefined should do?
    The reference named 'foo' itself has no relevance to bar when invoking
    bar(foo), only the *value* of foo has relevance. In particular,
    dojo.lang.isUndefined(undefined) correctly returns true.
    Again, not sure I understand what you mean.
    Using a global variable that may not exist (in any expression)
    requires
    window.foo or even dj_global.foo, possibly <context>["foo"] to
    support older
    IE.
    How much older IE do we need to support?
    If you really wanted to extend isUndefined to do safe global
    checking you
    would need to allow calls like so:

    isUndefined("foo"); // maps to isUndefined(window["foo"])
    isUndefined("foo", obj); // maps to isUndefined(obj["foo"])
    Yup I can see that being an extension. But you would think that if
    you know what the parent obj is of the thing you want to check you
    could just do:

    isUndefined(obj.foo);
    Regards,
    Scott J. Miles
    TurboAjax Group
    http://www.turboajax.com

    -----Original Message-----
    From: dojo-contributors-bounces@dojotoolkit.org
    On Behalf Of Jon
    Sykes
    Sent: Thursday, June 29, 2006 8:08 AM
    To: dojo dev.
    Subject: [dojo-contributors] Re: dojo.lang.isUndefined()

    Is there a reason that isUndefined is structured the way it is,
    such that an
    undefined variable/object will throw an error.

    dojo.lang.isUndefined = function(wh){
    return ((wh == undefined)&&(typeof wh == "undefined")); }

    if you do

    dojo.lang.isUndefined(foo);

    with no other reference to foo in your code it'll throw a JS error,
    becuase
    JS doesn't like checking for objects that don't exist, rather
    preferring you
    to checkf ro properties of existing objects.


    so...

    dojo.lang.isUndefined(window.foo);

    will return False as expected.

    I was just talking with Mr. Wiltshire about this, and one idea I
    had was
    that if you did:

    dojo.lang.isUndefined = function(wh){
    return ((typeof wh == "undefined")||(wh == undefined)); }

    That way actual real undefined objects will not fail, but will
    return false
    as expected. My logic being that I assume we're testing for two
    possible
    states, if the first in the above two is true it won't even try to
    do the
    second one (which throws the error) because we're using an OR, but
    if it
    doesn't it'll just check the second possible undefined to cover bases.

    Thoughts?

    Should I log this on Trac somewhere?

    I see that Alex has a trac at:

    http://trac.dojotoolkit.org/changeset/1418

    or should I add it to:

    http://trac.dojotoolkit.org/changeset/2118



    Jon Sykes


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Jon Sykes at Jun 29, 2006 at 12:38 pm
    Yup, I pasted what the function does now. Rather than what the
    function should do:

    if((typeof wh == "undefined")||(wh == undefined))alert("wh is
    undefined");

    Is what you are saying that if I did:

    if(!dojo.lang.isUndefined(foo)){

    foo(bar);

    }else{

    alert("OMG you tried to do something with foo and it doesn't exist);

    }


    would cause a JS error anyway?

    or would the above work if isUnDefined actually did test for
    undefined global objects with needing them to be tested as a property
    of an existing object?

    On Jun 29, 2006, at 2:30 PM, Scott J. Miles wrote:

    if((wh == undefined)&&(typeof wh == "undefined"))alert("foo is
    undefined");

    in to the firebug console and hit enter, if you don't have foo
    set, it will
    fire the alert. Isn't that what isUndefined should do? <<
    It looks like you didn't paste what you meant to paste: your
    example doesn't
    reference 'foo' at all. Putting what you did paste into the
    console, an
    exception is thrown because 'wh' cannot be evaluated as an operand
    to '==',
    which is exactly my point.
  • Scott J. Miles at Jun 29, 2006 at 1:00 pm
    What you are testing works fine if you test foo directly, i.e. (typeof foo
    == "undefined"). But it's not possible to build that test into a function.

    As I mentioned earlier, you are confusing foo itself with it's value.

    function bar(wh) { // wh always exists here, even if it's value ===
    undefined };
    bar(foo); // throws an exception if foo doesn't exist, before bar is even
    considered

    It works like this:
    1. function(<expression>) is invoked
    2. <expression> is evaluated to find a value to send to function

    This is what I meant by 'foo' itself being irrelevant to the function. Only
    the value of foo is relevant, and it's in trying to discover the value of
    foo that the exceptions is raised.

    Regards,
    Scott J. Miles
    TurboAjax Group
    http://www.turboajax.com

    -----Original Message-----
    From: dojo-contributors-bounces@dojotoolkit.org
    On Behalf Of Jon Sykes
    Sent: Thursday, June 29, 2006 11:39 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Re: dojo.lang.isUndefined()

    Yup, I pasted what the function does now. Rather than what the function
    should do:

    if((typeof wh == "undefined")||(wh == undefined))alert("wh is undefined");

    Is what you are saying that if I did:

    if(!dojo.lang.isUndefined(foo)){

    foo(bar);

    }else{

    alert("OMG you tried to do something with foo and it doesn't exist);

    }

    would cause a JS error anyway?

    or would the above work if isUnDefined actually did test for undefined
    global objects with needing them to be tested as a property of an existing
    object?

    On Jun 29, 2006, at 2:30 PM, Scott J. Miles wrote:

    if((wh == undefined)&&(typeof wh == "undefined"))alert("foo is
    undefined");

    in to the firebug console and hit enter, if you don't have foo set,
    it will fire the alert. Isn't that what isUndefined should do? <<
    It looks like you didn't paste what you meant to paste: your example
    doesn't reference 'foo' at all. Putting what you did paste into the
    console, an exception is thrown because 'wh' cannot be evaluated as an
    operand to '==', which is exactly my point.
  • Aaron Boodman at Jun 29, 2006 at 1:15 pm
    Also, in Firefox this will raise a warning in the JS console if strict
    mode is enabled. I just stopped writing code like this and used the
    typeof test directly each time. :-/

    - a
    On 6/29/06, Scott J. Miles wrote:
    What you are testing works fine if you test foo directly, i.e. (typeof foo
    == "undefined"). But it's not possible to build that test into a function.

    As I mentioned earlier, you are confusing foo itself with it's value.

    function bar(wh) { // wh always exists here, even if it's value ===
    undefined };
    bar(foo); // throws an exception if foo doesn't exist, before bar is even
    considered

    It works like this:
    1. function(<expression>) is invoked
    2. <expression> is evaluated to find a value to send to function

    This is what I meant by 'foo' itself being irrelevant to the function. Only
    the value of foo is relevant, and it's in trying to discover the value of
    foo that the exceptions is raised.

    Regards,
    Scott J. Miles
    TurboAjax Group
    http://www.turboajax.com

    -----Original Message-----
    From: dojo-contributors-bounces@dojotoolkit.org
    On Behalf Of Jon Sykes
    Sent: Thursday, June 29, 2006 11:39 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Re: dojo.lang.isUndefined()

    Yup, I pasted what the function does now. Rather than what the function
    should do:

    if((typeof wh == "undefined")||(wh == undefined))alert("wh is undefined");

    Is what you are saying that if I did:

    if(!dojo.lang.isUndefined(foo)){

    foo(bar);

    }else{

    alert("OMG you tried to do something with foo and it doesn't exist);

    }

    would cause a JS error anyway?

    or would the above work if isUnDefined actually did test for undefined
    global objects with needing them to be tested as a property of an existing
    object?

    On Jun 29, 2006, at 2:30 PM, Scott J. Miles wrote:

    if((wh == undefined)&&(typeof wh == "undefined"))alert("foo is
    undefined");

    in to the firebug console and hit enter, if you don't have foo set,
    it will fire the alert. Isn't that what isUndefined should do? <<
    It looks like you didn't paste what you meant to paste: your example
    doesn't reference 'foo' at all. Putting what you did paste into the
    console, an exception is thrown because 'wh' cannot be evaluated as an
    operand to '==', which is exactly my point.

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Alex Russell at Jun 29, 2006 at 3:55 pm

    On Thursday 29 June 2006 12:15 pm, Aaron Boodman wrote:
    Also, in Firefox this will raise a warning in the JS console if
    strict mode is enabled.
    Firefox's console is nearly useless these days. They really screwed up
    by logging CSS "errors". Thank god for Firebug.
    I just stopped writing code like this and
    used the typeof test directly each time. :-/
    Gah. That seems like giving up in the wrong place to me.

    Regards

    --
    Alex Russell
    alex@sitepen.com
    alex@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 188 bytes
    Desc: not available
    Url : http://dojotoolkit.org/pipermail/dojo-contributors/attachments/20060629/fd52c589/attachment-0001.pgp
  • Bob Ippolito at Jun 29, 2006 at 4:45 pm

    On Jun 29, 2006, at 2:55 PM, Alex Russell wrote:
    On Thursday 29 June 2006 12:15 pm, Aaron Boodman wrote:
    Also, in Firefox this will raise a warning in the JS console if
    strict mode is enabled.
    Firefox's console is nearly useless these days. They really screwed up
    by logging CSS "errors". Thank god for Firebug.
    I just stopped writing code like this and
    used the typeof test directly each time. :-/
    Gah. That seems like giving up in the wrong place to me.
    Well, it's not possible to write a function that tests whether a
    global is defined or not (unless you check them as properties of
    global object). That's what dj_undef does isn't it?

    -bob
  • Scott J. Miles at Jun 29, 2006 at 5:22 pm
    Well, it's not possible to write a function that tests whether a global
    is defined or not (unless you check [the name as string] as a property of
    global object). That's what dj_undef does isn't it? <<

    Yes, that's much clearer, I wish I'd just said that in the first place.
    That's exactly what dj_undef does.

    dj_undef("foo"); // tests window["foo"]
    dj_undef("foo", obj); // tests obj["foo"]

    Also, I thought I'd mention that dj_undef doesn't come up much if one is in
    the habit of namespacing application code.

    Regards,
    Scott J. Miles
    TurboAjax Group
    http://www.turboajax.com

    -----Original Message-----
    From: dojo-contributors-bounces@dojotoolkit.org
    On Behalf Of Bob Ippolito
    Sent: Thursday, June 29, 2006 3:46 PM
    To: dojo dev.; Alex Russell
    Cc: Aaron Boodman
    Subject: Re: [dojo-contributors] Re: dojo.lang.isUndefined()

    On Jun 29, 2006, at 2:55 PM, Alex Russell wrote:
    On Thursday 29 June 2006 12:15 pm, Aaron Boodman wrote:
    Also, in Firefox this will raise a warning in the JS console if
    strict mode is enabled.
    Firefox's console is nearly useless these days. They really screwed up
    by logging CSS "errors". Thank god for Firebug.
    I just stopped writing code like this and used the typeof test
    directly each time. :-/
    Gah. That seems like giving up in the wrong place to me.
    Well, it's not possible to write a function that tests whether a global is
    defined or not (unless you check them as properties of global object).
    That's what dj_undef does isn't it?

    -bob

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bob Ippolito at Jun 29, 2006 at 5:29 pm

    On Jun 29, 2006, at 4:22 PM, Scott J. Miles wrote:

    Well, it's not possible to write a function that tests whether a
    global
    is defined or not (unless you check [the name as string] as a
    property of
    global object). That's what dj_undef does isn't it? <<

    Yes, that's much clearer, I wish I'd just said that in the first
    place.
    That's exactly what dj_undef does.

    dj_undef("foo"); // tests window["foo"]
    dj_undef("foo", obj); // tests obj["foo"]

    Also, I thought I'd mention that dj_undef doesn't come up much if
    one is in
    the habit of namespacing application code.
    If you wanted to be pedantic...

    dojo.global().dj_undef("foo");

    :)

    -bob
  • Jon Sykes at Jun 29, 2006 at 9:10 pm
    We were just bouncing some ideas round here:

    var bar;
    foo = new Object;
    foo.bar = new Object;

    function isUndefined(varname){
    try{
    eval(varname);
    return(false);
    }catch(e){
    //alert(e.message);
    if(e.message.match('defined')){return true;}
    }
    }



    alert("bar is "+isUndefined('bar')+".");
    alert("foo is "+isUndefined('foo')+".");
    alert("foo.bar is "+isUndefined('foo.bar')+".");
    alert("foobar is "+isUndefined('foobar')+".");


    But it's cheating really to have to supply the potential object as a
    string.

    Also assuming that matching "defined" in the error is enough is
    probably problematic, it covers "undefined" and "not defined" but
    isn't exactly rock solid.

    Anyway, that was fun, back to business.

    Jon Sykes

    On Jun 29, 2006, at 6:45 PM, Bob Ippolito wrote:

    Well, it's not possible to write a function that tests whether a
    global is defined or not (unless you check them as properties of
    global object). That's what dj_undef does isn't it?
  • Bob Ippolito at Jun 29, 2006 at 9:31 pm
    It's not cheating, it's just broken. That only works for objects in
    the global scope, local scope doesn't carry through function calls
    and JavaScript doesn't have macros. Don't pass go, don't collect $200.

    -bob
    On Jun 29, 2006, at 8:10 PM, Jon Sykes wrote:

    We were just bouncing some ideas round here:

    var bar;
    foo = new Object;
    foo.bar = new Object;

    function isUndefined(varname){
    try{
    eval(varname);
    return(false);
    }catch(e){
    //alert(e.message);
    if(e.message.match('defined')){return true;}
    }
    }



    alert("bar is "+isUndefined('bar')+".");
    alert("foo is "+isUndefined('foo')+".");
    alert("foo.bar is "+isUndefined('foo.bar')+".");
    alert("foobar is "+isUndefined('foobar')+".");


    But it's cheating really to have to supply the potential object as
    a string.

    Also assuming that matching "defined" in the error is enough is
    probably problematic, it covers "undefined" and "not defined" but
    isn't exactly rock solid.

    Anyway, that was fun, back to business.

    Jon Sykes

    On Jun 29, 2006, at 6:45 PM, Bob Ippolito wrote:

    Well, it's not possible to write a function that tests whether a
    global is defined or not (unless you check them as properties of
    global object). That's what dj_undef does isn't it?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Aaron Boodman at Jun 30, 2006 at 5:24 pm

    On 6/29/06, Alex Russell wrote:
    I just stopped writing code like this and
    used the typeof test directly each time. :-/
    Gah. That seems like giving up in the wrong place to me.
    At G, we don't like to rely on obj["foo"] and obj.foo being the same
    since the fancy compiler likes to change obj.foo to obj.a. So I don't
    know if there's anywhere to go from there.

    - a
  • Dean Edwards at Jun 29, 2006 at 5:30 pm

    Aaron Boodman wrote:
    Also, in Firefox this will raise a warning in the JS console if strict
    mode is enabled. I just stopped writing code like this and used the
    typeof test directly each time. :-/
    IE returns "unknown" for some typeof tests. At least they are honest. ;-)

    -dean
  • Scott J. Miles at Jun 29, 2006 at 6:13 pm
    IE returns "unknown" for some typeof tests. At least they are honest. ;-)
    In that case, the dj_undef test should probably look like:

    return (!(name in object) || (typeof object[name] == "undefined"));

    Regards,
    Scott J. Miles
    TurboAjax Group
    http://www.turboajax.com

    -----Original Message-----
    From: dojo-contributors-bounces@dojotoolkit.org
    On Behalf Of Dean Edwards
    Sent: Thursday, June 29, 2006 4:31 PM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Re: dojo.lang.isUndefined()

    Aaron Boodman wrote:
    Also, in Firefox this will raise a warning in the JS console if strict
    mode is enabled. I just stopped writing code like this and used the
    typeof test directly each time. :-/
    IE returns "unknown" for some typeof tests. At least they are honest. ;-)

    -dean
  • Dean Edwards at Jun 29, 2006 at 6:31 pm

    Scott J. Miles wrote:
    IE returns "unknown" for some typeof tests. At least they are honest. ;-)
    In that case, the dj_undef test should probably look like:

    return (!(name in object) || (typeof object[name] == "undefined"));
    The |in| operator when used like the example above does not work for
    IE5.0 IIRC. Do you guys care about IE5.0? I'm assuming you do.

    -dean
  • Tom Trenka at Jun 30, 2006 at 9:00 am
    Dean,
  • Dean Edwards at Jun 30, 2006 at 9:17 am

    On 30/06/06, Tom Trenka wrote:
    Dean,

    From the website:
    Safari 2.0.x+
    Opera 8.5+
    Internet Explorer (Windows) 5.5+
    Firefox 1.0+/Mozilla
    Konqueror 3.5+

    ...so no, we're not really supporting IE 5.0.
    I'm suprised. IE5.0 has a larger user base than Opera/Konqueror
    combined. Peculiarly, it also has a larger user base than IE5.5 [1].

    -dean

    [1] http://www.currybet.net/articles/user_agents/5.php
  • Alex Russell at Jun 30, 2006 at 2:48 pm

    On Friday 30 June 2006 8:17 am, Dean Edwards wrote:
    On 30/06/06, Tom Trenka wrote:
    Dean,

    From the website:
    Safari 2.0.x+
    Opera 8.5+
    Internet Explorer (Windows) 5.5+
    Firefox 1.0+/Mozilla
    Konqueror 3.5+

    ...so no, we're not really supporting IE 5.0.
    I'm suprised. IE5.0 has a larger user base than Opera/Konqueror
    combined. Peculiarly, it also has a larger user base than IE5.5 [1].
    That's the power of being the default install browser on an OS when it
    goes RTM, and why the pathetic joke that is IE 7 is going to be another
    long-term albatros since it'll the be the RTM browser for Vista.

    /me sighs

    --
    Alex Russell
    alex@sitepen.com A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
    alex@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 188 bytes
    Desc: not available
    Url : http://dojotoolkit.org/pipermail/dojo-contributors/attachments/20060630/76c25e10/attachment.pgp
  • Dean Edwards at Jun 30, 2006 at 7:06 pm

    Alex Russell wrote:
    On Friday 30 June 2006 8:17 am, Dean Edwards wrote:
    On 30/06/06, Tom Trenka wrote:

    ...so no, we're not really supporting IE 5.0.
    I'm suprised. IE5.0 has a larger user base than Opera/Konqueror
    combined. Peculiarly, it also has a larger user base than IE5.5 [1].
    That's the power of being the default install browser on an OS when it
    goes RTM, and why the pathetic joke that is IE 7 is going to be another
    long-term albatros since it'll the be the RTM browser for Vista.
    Politics?

    This to me is a very crucial decision in designing and implementing a
    library.

    In real terms, the difference between supporting IE5.0 and IE5.5 is it's
    differing support for core JavaScript. Namely, the various Array methods
    (pop/push etc) and more importantly, Function.apply/call. In terms of
    HTML/CSS there are few differences. So DHTML is easy.

    To support IE5.0 all you have to do is add support for Array.push/pop et
    al and Function.apply/call. However, I'm assuming that you don't want to
    mess with native objects, right?

    -dean
  • Alex Russell at Jun 30, 2006 at 7:12 pm

    On Friday 30 June 2006 6:09 pm, Dean Edwards wrote:
    Alex Russell wrote:
    On Friday 30 June 2006 8:17 am, Dean Edwards wrote:
    On 30/06/06, Tom Trenka wrote:
    ...so no, we're not really supporting IE 5.0.
    I'm suprised. IE5.0 has a larger user base than Opera/Konqueror
    combined. Peculiarly, it also has a larger user base than IE5.5
    [1].
    That's the power of being the default install browser on an OS when
    it goes RTM, and why the pathetic joke that is IE 7 is going to be
    another long-term albatros since it'll the be the RTM browser for
    Vista.
    Politics?
    Don't think so, it's just the way it is. Every time I've talked to folks
    on the IE team, they seem well-intentioned and totally at the mercy of
    machinery over which they have no control. It's really dispiriting.

    Obviously they don't put it that way, and they are trying as hard as
    they can, but I think it's pretty clear how the lines are drawn.
    This to me is a very crucial decision in designing and implementing a
    library.

    In real terms, the difference between supporting IE5.0 and IE5.5 is
    it's differing support for core JavaScript. Namely, the various Array
    methods (pop/push etc) and more importantly, Function.apply/call. In
    terms of HTML/CSS there are few differences. So DHTML is easy.

    To support IE5.0 all you have to do is add support for Array.push/pop
    et al and Function.apply/call.
    That's not true at all. There are significant definciencies in various
    parts of older JScript engines, including core parsing bugs,
    uncatchable exceptions, and issues with instanceof. The DOM limitations
    and associated network level issues are also problematic.
    However, I'm assuming that you don't
    want to mess with native objects, right?
    IE 5.0 was released *last century* and AFAICT is out of support for all
    but the most gigantic and persistent Microsoft customers. You can't
    even *buy* an OS on the open market that runs it by default any more.
    We've gotta draw a line somewhere.

    Regards

    --
    Alex Russell
    alex@sitepen.com A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
    alex@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 188 bytes
    Desc: not available
    Url : http://dojotoolkit.org/pipermail/dojo-contributors/attachments/20060630/63482513/attachment.pgp
  • Dean Edwards at Jul 1, 2006 at 1:12 pm

    Alex Russell wrote:
    On Friday 30 June 2006 6:09 pm, Dean Edwards wrote:
    To support IE5.0 all you have to do is add support for Array.push/pop
    et al and Function.apply/call.
    That's not true at all. There are significant definciencies in various
    parts of older JScript engines, including core parsing bugs,
    uncatchable exceptions, and issues with instanceof. The DOM limitations
    and associated network level issues are also problematic.
    All browsers have some problems or another. The ones you outline don't
    seem insurmountable. I'm not aware of any problems with instanceof but
    that may just have escaped me somehow.
    IE 5.0 was released *last century* and AFAICT is out of support for all
    but the most gigantic and persistent Microsoft customers. You can't
    even *buy* an OS on the open market that runs it by default any more.
    That's not really a technical reason. The point is that there are a lot
    of web users with old operating systems that run IE5.0. They won't
    upgrade their browser until they buy a new computer. And they won't buy
    a new computer until the old one dies.
    We've gotta draw a line somewhere.
    Fair enough. But so do my clients. They all want support for IE5.0.

    You are not on your own. None of the major libraries support this
    browser. At least you support IE5.5. :-)

    -dean
  • Bob Ippolito at Jul 1, 2006 at 1:43 pm

    On Jul 1, 2006, at 12:17 PM, Dean Edwards wrote:

    Alex Russell wrote:
    On Friday 30 June 2006 6:09 pm, Dean Edwards wrote:
    To support IE5.0 all you have to do is add support for Array.push/
    pop
    et al and Function.apply/call.
    That's not true at all. There are significant definciencies in
    various parts of older JScript engines, including core parsing
    bugs, uncatchable exceptions, and issues with instanceof. The DOM
    limitations and associated network level issues are also problematic.
    All browsers have some problems or another. The ones you outline
    don't seem insurmountable. I'm not aware of any problems with
    instanceof but that may just have escaped me somehow.
    IE 5.0 was released *last century* and AFAICT is out of support
    for all but the most gigantic and persistent Microsoft customers.
    You can't even *buy* an OS on the open market that runs it by
    default any more.
    That's not really a technical reason. The point is that there are a
    lot of web users with old operating systems that run IE5.0. They
    won't upgrade their browser until they buy a new computer. And they
    won't buy a new computer until the old one dies.
    We've gotta draw a line somewhere.
    Fair enough. But so do my clients. They all want support for IE5.0.

    You are not on your own. None of the major libraries support this
    browser. At least you support IE5.5. :-)
    I don't think anyone would complain if you stepped up to test and
    maintain IE 5.0 support for Dojo. I doubt anyone else wants to.

    -bob
  • Tom Trenka at Jul 1, 2006 at 1:57 pm
    Dean,

    You're right: instanceof was added (as well as all error handling)
    with the introduction of IE5.0 (which corresponds to JScript 5.0).
    Other things are not there (full support for properties on RegExp,
    things like hasOwnProperty, etc.) but most of those are
    inconsequential.

    My understanding is that the MS XML SDK 2.0 was released with IE
    4.01sp1 and IE5.0; this would mean that the very first version of XML
    HTTP was shipped with 5.0, and that wasn't the most stable version in
    the world...which makes doing AJAX dev against it difficult.

    This is one of those "how much to support" questions...as Alex said,
    IE5.0 was released last century, and the workarounds to ensure
    compatibility are too much of a burden for not enough gain (IMHO). At
    that point we should try to support NN4 as well, and I don't think
    that's a viable option.

    Note that we're also not supporting IE5/Mac, which (in my mind) would
    be a little bit more important to support, since that is a much more
    recent browser.

    trt
    On 7/1/06, Dean Edwards wrote:
    Alex Russell wrote:
    On Friday 30 June 2006 6:09 pm, Dean Edwards wrote:
    To support IE5.0 all you have to do is add support for Array.push/pop
    et al and Function.apply/call.
    That's not true at all. There are significant definciencies in various
    parts of older JScript engines, including core parsing bugs,
    uncatchable exceptions, and issues with instanceof. The DOM limitations
    and associated network level issues are also problematic.
    All browsers have some problems or another. The ones you outline don't
    seem insurmountable. I'm not aware of any problems with instanceof but
    that may just have escaped me somehow.
    IE 5.0 was released *last century* and AFAICT is out of support for all
    but the most gigantic and persistent Microsoft customers. You can't
    even *buy* an OS on the open market that runs it by default any more.
    That's not really a technical reason. The point is that there are a lot
    of web users with old operating systems that run IE5.0. They won't
    upgrade their browser until they buy a new computer. And they won't buy
    a new computer until the old one dies.
    We've gotta draw a line somewhere.
    Fair enough. But so do my clients. They all want support for IE5.0.

    You are not on your own. None of the major libraries support this
    browser. At least you support IE5.5. :-)

    -dean
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Dean Edwards at Jul 3, 2006 at 12:49 pm

    Tom Trenka wrote:
    You're right: instanceof was added (as well as all error handling)
    with the introduction of IE5.0 (which corresponds to JScript 5.0).
    Other things are not there (full support for properties on RegExp,
    things like hasOwnProperty, etc.) but most of those are
    inconsequential. Agreed.
    My understanding is that the MS XML SDK 2.0 was released with IE
    4.01sp1 and IE5.0; this would mean that the very first version of XML
    HTTP was shipped with 5.0, and that wasn't the most stable version in
    the world...which makes doing AJAX dev against it difficult.
    I'm not really an Ajax man so I'll take your word for it.
    This is one of those "how much to support" questions...as Alex said,
    IE5.0 was released last century, and the workarounds to ensure
    compatibility are too much of a burden for not enough gain (IMHO).
    Fair enough. I mistakenly assumed that you were supporting it. That's
    what started this discussion.
    Note that we're also not supporting IE5/Mac, which (in my mind) would
    be a little bit more important to support, since that is a much more
    recent browser.
    Unfortunately, OS9 users don't really have any alternatives.

    -dean
  • Alex Russell at Jul 3, 2006 at 11:58 pm

    On Monday 03 July 2006 11:53 am, Dean Edwards wrote:
    Note that we're also not supporting IE5/Mac, which (in my mind)
    would be a little bit more important to support, since that is a
    much more recent browser.
    Unfortunately, OS9 users don't really have any alternatives.
    IE 5.x for the Mac is a total and utter loss. Any reasonably complex
    DHTML in Tasman is a no-go due to serious rendering issues and core
    language parsing bugs. Whatever issues IE 5 on the PC may have had,
    they were nothing compared to Tasman.

    It's also not that much "newer", as it's rendering engine was released
    in spring of '00...more than 6 years ago. It barely squeeked into this
    decade and has seen almost no significant improvements since that
    initial release (AFAICT)....at least none that made it out into a
    public release.

    We have a "fallback to non-upgraded content" strategy for a
    reason...Tasman is just one of those reasons.

    Regards

    --
    Alex Russell
    alex@sitepen.com A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
    alex@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 188 bytes
    Desc: not available
    Url : http://dojotoolkit.org/pipermail/dojo-contributors/attachments/20060703/c40c9399/attachment.pgp
  • Bob Ippolito at Jun 29, 2006 at 6:49 pm

    On Jun 29, 2006, at 5:13 PM, Scott J. Miles wrote:

    IE returns "unknown" for some typeof tests. At least they are
    honest. ;-)
    In that case, the dj_undef test should probably look like:

    return (!(name in object) || (typeof object[name] == "undefined"));
    I don't think the given statement was specific enough to know that
    the existing code is wrong and determine that the above code is the
    right solution. Maybe it returns "unknown" for some typeof tests such
    that the object is defined but its type is ambiguous somehow? I'd ask
    for a test that proves that it returns "unknown" sometimes so that
    you could check to see whether dj_undef does the right thing in those
    cases.

    -bob

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedJun 29, '06 at 9:07a
activeJul 3, '06 at 11:58p
posts28
users7
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase