Anticipating a possible objection, it would mean that such a version N+1 would not be upwards/backwards compatible with version N. But this is already the case. If SES sees a property that it does not know about and that it cannot remove, it must refuse to load because it must assume that it has encountered an insecurable platform.
Introducing new string-named non-configurable properties on existing built-ins should only be done when there's no other good choice, because of this incompatibility. This is true whether we adopt Kevin's suggestion or not. On Fri, Oct 26, 2012 at 6:04 PM, Mark S. Miller <[email protected]> wrote: > > On Fri, Oct 26, 2012 at 5:45 PM, Waldemar Horwat <[email protected]>wrote: > >> >>> How about: there must be no /nonstandard non-configurable properties/ of >>> standard objects. >>> >> >> Wouldn't that just preclude us from ever adding new standard >> non-configurable properties to standard objects in the future? > > > AFAICT, it would mean that, if these properties become standard starting > in version N+1, an implementation conforming to version N must either > * not have these properties, > * must have them be configurable, or > * must instead claim that it is now attempting conformance with N+1. > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
