« Bugzilla Issues Index

#1222 — MakeSecureObject and TestIfSecureObject are misleading names

These certainly do not make an object secure nor verify if it is secure. Perhaps you mean "defensible"? MakeDefensibleObject" and TestIfDefensibleObject would be ok. Note that "defensive" is also wrong, as this enables an object to defend itself but does not ensure that it does.

I know Tom suggested "tamper proof", but we're already using that for something more specific -- where configurable data properties on prototypal objects are locked down by turning them into accessor properties that allow override by assignment. (Needed, since we didn't fix the override mistake)

fixed in rev 14 editor's draft

Switching to SetIntegrityLevel terminology

in Rev 14 draft