Forums

YUI cuts off prototype properties of configuration objects, which seems like an unnecessary inconvenience. Here is an example of what I meant.

It’s because of things like this in Base:



So, when I’ve done this:



…then “instance” will not have visible:false, since the hasOwnProperty() check weeds it out.

This doesn’t seem very useful or desirable. As I understand, the intent of the hasOwnProperty() check in YUI is to prevent Object.prototype extensions from bleeding into all object iterations, esp. from Prototype.js. That being the case, ISTM it would be an improvement to check for *exactly* that, rather than killing all inherited properties. Something like:

https://gist.github.com/1351541

Then, we can do this (which seems easier to read anyhow):


…and we weed out anything added to Object.prototype, without killing off any other inheritance that implementers (ahem!!) may have in mind.

The hasOwnProperty() check seems to prevent implementers from using prototypal inheritance in this way. ISTM a better approach would be to be paradigm-agnostic.

I've taken Felipe's view on this in past conversations (https://github.com/rgrove/yui3/commit/6 ... ent-408918).

It's a trade-off.

a) Do we want to remove the fragility [1] from our code, by iterating more than the top-most level in the prototype chain?
b) Do we want to try and protect people from the fragility caused by external code futzing with native prototypes?

Both a) and b) have more than a small chance of causing breakage in the real world.

We're choosing to go with b) and spreading fragility throughout our system, in order to nanny external implementations. I don't think that's the right trade-off option to pick.

There are way more ways in which people can futz with the native JS and DOM environment than just adding onto the Object prototype, and we don't try to nanny all those scenarios. It's a losing battle which we're fighting at the expense of the library's usability.

Flattening objects has the same issues as deciding what the filtering criteria should be if we want to iterate more than the top level properties in the prototype chain. It doesn't really provide a solution in and of itself, but is probably good sugar to have.

Regarding iteration:

For most config iteration [2], whitelists can usually be applied, and I would suggest we change to the non-HOP whitelist mix which I did for parts of Base/Attribute (see github commit discussion link above).

For non-whitelist/open-ended iteration, if we really want to try and play nanny for implementations which mess with Object prototype, we could do something like this which seems like it would probably work for our use cases with minimal overhead, and works across A-Grade:

var OBJECT = {},
p;

for ( p in o ) {
if ( !(p in OBJECT) ) {
// o[p] is good to work with.
}
}

http://yuiblog.com/sandbox/yui/v340/nannying.html

The only issue I see off the top of my head is potentially not iterating native enumerable properties from Object.prototype, which it doesn't seem like we want to do anyway. There may be other issues.

Satyen

[1] Fragility of the type Felipe hit. And by any definition, it is fragility. When you pass an object to a method which asks for an object, you expect the object to be worked on as a whole, not just it's top-most prototype properties - that's just an arbitrary artifact of the nannying trade-off path we chose.

[2] This conversation is not limited to configs of course.

As mentioned, the simpler version I provided is designed to weed out properties we may iterate over due to implementations messing with Object.prototype (which is what your edge case describes and is bad practice for the reasons we're discussing), as a replacement for what we were trying to use hasOwnProperty for. That is, if, in your edge case, you don't mess with Object.prototype, then it should work fine.

Performance is a factor. A lot of this iteration happens along critical paths [events, attribute, base etc.] and traversing the prototype chain for each property we iterate is expensive, however A-Grade support is also a factor in using getPrototypeOf (or __proto___).

I agree, ideally if we could identify non-native properties added to Object.prototype across the A-Grade, and just avoid those, that would be perfect.

Short of that, *if* we really want to try and protect people from other implementations which mess with Object.prototype, then the above seems like a reasonable solution given the constraints and pros/cons on the table.

Is the edge case you describe something in your actual implementation?

I believe IE7 is still considered A-Grade and has no way to determine the prototype of a particular object.

Only if you don't override constructor accidentally or maliciously.