On Nov 26, 2012, at 9:44 AM, Tom Van Cutsem wrote: > 2012/11/25 Allen Wirfs-Brock <[email protected]> > > On Nov 25, 2012, at 12:41 PM, Tom Van Cutsem wrote: >> >> However, with [[HasProperty]] removed, I assume the "in"-operator no longer >> triggers the "has" trap when it encounters a proxy, instead doing the >> proto-chain-walk itself and calling "hasOwn" on each level. This is OK, >> although it introduces an inconsistency with the other proto-chain-walking >> algorithms, which stop when encountering a proxy, letting the proxy take >> over from that point (this is the case for the "get", "set" and "enumerate" >> traps). > > [[HasProperty]] is replaced with a HasProperty abstract operation (9.3.6) > that indeed makes generic calls to [[HasOwnProperty]] and [[GetInheritance]] > in a loop. This also slightly bothers me. I guess I convinced my self that > an object that wanted to use a non-standard inheritance path could hide that > by reporting its inherited properties to be own properties. > > I also occasionally find it troubling inheritance semantics are replicated > in three different places [[GetP]], [[SetP]], and HasProperty and that it is > quite possible to get them out of sync. I've come to accept the > replication/possible inconsistency but maybe we really do need to bring back > [[HasProperty]] so that it is possible to consistently over-ride all three. > I'd might be happy to swap [[Feeze]]/[[Seal]]/i[[sFrozen]]/[[isSealed]] for > [[HasProperty]] :-) > > Yes, this is a good point: one must be able to consistently override all > inheritance-related operations. Requiring an object with multiple prototypes > to report all inherited properties as "own" feels broken. > > W.r.t. freeze and friends, I thought you were considering a more generic > [[GetIntegrity]]/[[SetIntegrity]] operation.
Yes, are you on board with that? > > Cheers, > Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
