that's not really valid, undefined is as valuable as null when checking an object; just write a handler and drop it onto the array prototype.
On Feb 16, 7:08 am, Jason Persampieri <[email protected]> wrote: > (It's 4am for me, I'm sick, and meds have been taken... so this may be > incredibly dumb) > > An earlier thread got me thinking. Currently when checking a value nested > several layers deep within an object, you have to do something along the > lines of: > > d = {}; > [stuff] > if ( d && d.foo && d.foo.bar && d.foo.bar.bam ) { > [stuff] > > } > > And setting it is even more verbose: > d = {}; > d.foo = d.foo || {}; > ... you get the point. > > What would happen if "undefined" were smarter, kinda like an empty ref in > Perl (did I really just say that? ugh.). Why can't we do: > > d = {}; > [stuff] > if ( d.foo.bar.bam ) { > [stuff] > > } > > and > > d = {}; > d.foo.bar.bam = "Hi Mentors!"; // { foo: { bar: { bam: "Hi Mentors!" } } } > > What's the harm in having the compiler do that bit of optimization for us? > What code would it break? Is there any code that it would make less > maintainable? Do custom getters/setters break this? > > _jason -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
