« Bugzilla Issues Index
#1222 — MakeSecureObject and TestIfSecureObject are misleading names
- bug_id:
1222
- creation_ts:
2013-01-26 11:31:00 -0800
- short_desc:
MakeSecureObject and TestIfSecureObject are misleading names
- delta_ts:
2013-03-08 14:44:24 -0800
- product:
Draft for 6th Edition
- component:
editorial issue
- version:
Rev 13: December 21, 2012 Draft
- rep_platform:
All
- op_sys:
All
- bug_status:
RESOLVED
- resolution:
FIXED
- priority:
Normal
- bug_severity:
major
- everconfirmed:
true
- reporter:
Mark Miller
- assigned_to:
Allen Wirfs-Brock
- commentid:
3153
- comment_count:
0
- who:
Mark Miller
- bug_when:
2013-01-26 11:31:38 -0800
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)
- commentid:
3215
- comment_count:
1
- who:
Allen Wirfs-Brock
- bug_when:
2013-02-25 15:17:08 -0800
fixed in rev 14 editor's draft
Switching to SetIntegrityLevel terminology
- commentid:
3363
- comment_count:
2
- who:
Allen Wirfs-Brock
- bug_when:
2013-03-08 14:44:24 -0800
in Rev 14 draft