At the Thursday, August 21, ES3.1 design conference call we debated two decision points relating to property attributes but did not reach consensus on either item. There are strong points on each side of these issues but so far too few contributors have weighed in to reach any consensus on the alternatives. We would like to make a final decision during the next conference call (Tuesday August 26) but in preparation we would like to get the opinion of more of the community. If, after reviewing the alternatives below, you have an opinion replay to the list and please call in Tuesday if you are a TC-39 member who wants to help make the final decision.
Issue 1: When a property is defined using Object.defineProperty and similar functions what are the values of any properties attributes that are not explicitly specified using the property descriptor argument. Background: The attributes we are talking about are [[Writable]], [[Enumerable]], [[Flexible]]. See ES3.1 Draft Sections 8.6.1, 8.6.2.9, 15.2.3.7 and similar functions in 15.2.3. "Proposed ECMAScript 3.1 Static Object Functions: Use Cases and Rationale" http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:rationale_for_es3_1_static_object_methods.pdf Alternative #1: When creating a property using defineProperty all unspecified attributes default to false. * A major goal of ES3.1 and beyond is to make ES a better language for writing high integrity software. * The attribute names were chosen such that they affirmatively name a privilege associated with a property. A true value means the privilege is granted to the program and a false value means that it is withheld. * We know from experience that programmers are "lazy" and that if a specific attribute setting is not essential to their application they will usually just not specify it in a defineProperty descriptor. * Following the "principle of least authority", a privilege should only be granted if it is explicitly requested. * Defaulting attributes to anything but false violates POLA and makes it more difficult to write high integrity software. * Few casual or unsophisticated programmers will be using defineProperty or the other functions that use property desciptors. Alternative #2: When creating a property using defineProperty all unspecified attributes default to the same values they have when a property is created by assignment or within an object literal. * The "normal" way to define properties is via assignment or within an object literal. The attribute values implicitly set by these syntactic forms are defined by ES3 and previous editions to be the equivalent of setting each of [[Writable]], [[Enumerable]], and [[Flexible]] to true. * Object.defineProperty is a supplemental mechanism for use in situations when non-default attribute values are required and for other out of the ordinary scenarios. * Because of compatibility constraints, we cannot change the attributes that are implicitly set by existing syntactic forms. * The consistency principle suggests that in all situations where attribute value are implicitly specified, their implicit default values should be the same. * Inconsistencies makes it harder to learn and use the language. * The majority of ES programmers are unsophisticated and are not trying to write high integrity software. * Usability for a minority of users should not be achieved at the expense of decreasing usability for the majority. Issue 2: The property attribute currently named [[Flexible]] (and which replaces ES3's [[dontDelete]]) should be renamed to [[Configurable]]. Argument for: * The common meaning of the word "configurable" is a closer match to the actual semantics of the attribute than the common meaning of "flexible" * The other attributes name all follow the form of a semantically meaningful verb ("write" and "enumerate") converted to an adjective by adding "able". "flex" is not semantically meaningful within ES. * If we had thought of "configurable" when we considering names we probably would have chosen it over "flexible". Argument against: * "configurable" is too long and long names make programs less readable. * This will be particularly true for Object.defineProperty calls if alternative #2 above is chosen and programmers who care about high integrity software must frequently say "configurable:false" in property descriptors.
_______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
