If a proxy implementor doesn't faithfully implement the semantics of a trap (i.e. a getPropertyNames() trap that doesn't appear to take the prototype chain into account, one way or another), then all bets re. consistency are off anyway, regardless of the default semantics we choose for getPropertyDescriptor and getPropertyNames.
That said, I still agree with your suggestion: if getPropertyDescriptor and getPropertyNames become derived traps, I think the simplest choice is to define them directly in terms of fundamental traps only. Like this, traps can still be clearly categorized as either "fundamental" or "derived". Otherwise, you end up with an "in between" category of traps that are themselves derived, yet can still be invoked as part of the default implementation of other missing derived traps. >From another point of view, it's probably a good idea to try and minimize the number of traps that can be called by the implementation due to missing derived traps. This behavior is probably already surprising enough as it is for proxy programmers. Cheers, Tom 2011/1/25 David Bruant <bru...@enseirb-matmeca.fr> > Hi, > > If 'getPropertyNames' and 'getPropertyDescriptor' becomes derived traps, > then one question arises: > Should derived traps be defined only thanks to fundamental traps or thanks > to what Mark Miller called in a previous e-mail "remaining traps" (what I > understand as all the rest, modulo obviously avoiding interdepencies > issues)? This question doesn't need to be asked if 'getPropertyNames' and > 'getPropertyDescriptor' are fundamental, but since some default behavior of > derived traps requires them, it's a different story if they become derived. > > Let's assume for the rest of this e-mail that they become derived. > The current defaut 'enumerate' trap uses both 'getPropertyNames' and > 'getPropertyDescriptor'. We have (at least) two choices: keep the current > definition that uses them or doing one which only uses 'getOwnPropertyNames' > and 'getOwnPropertyDescriptor'. > If someone decides to explicitly implement only the 5 fundamental + > 'getPropertyNames' and 'getPropertyDescriptor', then depending on the > enumerate definition we choose, the result will be different if the > handler's get(Own)Property(Descriptor|Names) definitions aren't consistent > with the "climbing prototype chain" idea. > > I am just raising the question now, I do not have strong convictions on > what should be the rational behind default dehaviors. I would suggest to > only use fundamental traps (even though it may result in longer code). This > way we /could/ provide some garantees like prototype chain climbing and > delegation to fundamental trap of prototypes if they are proxies themselves. > If people aren't satisfied with this garantee, they can redefine the method > anyway. > But I kind of like the idea that if my prototype chain is filled with > proxies, method (like enumerate) which are supposed to climb the proto chain > do it for me even though I have redefined methods which are usually supposed > to climb it such as getPropertyDescriptor. > > > Another concern on derived trapped definition is other traps returned > values. I however notice that this point is written in the open issue of > dealing with inconsistent data returned by handler traps, so i won't go > further. > > Cheers, > > David >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
