Actually, here ...
Object.prototype.define = function(args) {
if (typeof(args) != "object") { throw "Expected an Object"; }
for (var i in args) { this[i] = args[i]; }
return this;
};
On Feb 16, 9:39 am, Jason Mulligan <[email protected]>
wrote:
> 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]
