new function syntax and poison pill methods

Mark S. Miller erights at
Fri Oct 26 18:11:06 PDT 2012

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

On Fri, Oct 26, 2012 at 6:04 PM, Mark S. Miller <erights at> wrote:

> On Fri, Oct 26, 2012 at 5:45 PM, Waldemar Horwat <waldemar at>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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list