On Jul 12, 2011, at 2:54 AM, Andreas Rossberg wrote: > On 9 July 2011 17:48, Brendan Eich <bren...@mozilla.com> wrote: >> > > Moreover, the distinction between names and proper > objects will have to be deeply engrained in the spec, because it > changes a fundamental mechanism of the language. Whereas WeakMaps are > more of an orthogonal feature with rather local impact on the spec.
Not a big deal for the spec. One short ToPropertyKey algorithm in clause 9 and calls to it in a handful of places. > > I think an efficient implementation of names in something like V8 will > probably want to assign different internal type tags to them either > way. Otherwise, we'll need extra tests for each property access, and > cannot specialise as effectively. > Isn't that pretty much a wash either way > >> I'm not sure which "class" you mean. The [[ClassName]] disclosed by >> Object.prototype.toString.call(x).slice(8,-1) is one possibility, which is >> one of the many and user-extensible ways of distinguishing among >> objects. ES.next class is just sugar for constructor/prototype patterns >> with crucial help for extends and super. > > I meant the [[Class]] property (I guess that's what you are referring > to as well). Not sure what you mean when you say it is > user-extensible, though. Is it in some implementations? (I'm aware of > the somewhat scary note on p.32 of the spec.) Or are you just > referring to the toString method? Because Table 8 says all objects (including host objects) have a string valued [[Class]] property, some people and third party specifications (and perhaps some implementations) have assumed that [[Class]] is an specified extension mechanism for Object.prototype.toString. To eliminate any such confusion, in the initial draft for the 6th edition spec. I have eliminated [[Class]] and replaced it with non-parameterized object brands using distinct internal properties. I will make that draft available within the next 24 hours. > > > I appreciate the ongoing discussion, but I'm somewhat confused. Can I > ask a few questions to get a clearer picture? > > 1. We seem to have (at least) a two-level nominal "type" system: the > first level is what is returned by typeof, the second refines the > object type and is hidden in the [[Class]] property (and then there is > the oddball "function" type, but let's ignore that). You can certainly read it that way. The real nominal types of ECMAScript are defined in clause 8. Only the "ECMAScript language types" subset are exposed to ECMAScript programmers. The "specification types" subset are just that, specification devices. One of these nominal types is object. Specific kinds of objects are classified and discriminated in various ways within the specification (including via the value of [[Class]]). If you wish to thing of these categorization schemes as "nominal types" you can but the specification does not define them as such. In particular, it does not define any rules for forming such nominal types and it does not impose any orthogonality requirements on the categorization schemes. Essentially, this is an ad hoc layer that has been used for specification convenience. > Is it the > intention that all "type testing" predicates like isArray, isName, > isGenerator will essentially expose the [[Class]] property? Absolutely not. But note that that these are not "type testing" in the sense that ES uses the work "type". They discriminate different kinds (categorizations) of objects but ES does not define these as types. This is not an unusual dichotomy. For example, if you define Integer to be a type, what do you consider odd integers to be? Another layer of typing or just a further subcategorization of the member of the Integer type. > > 2. If there are exceptions to this, why? Would it make sense to clean > this up? (I saw Allen's cleanup strawman, but it seems to be going the > opposite direction, and I'm not quite sure what it's trying to achieve > exactly.) see the associated google doc: https://docs.google.com/document/d/1sSUtri6joyOOh23nVDfMbs1wDS7iDMDUFVVeHeRdSIw/edit?hl=en_US&authkey=CI-FopgC [[Class]] has caused all sorts of confusion in the realm of host objects. It's use in the spec. has also resulted in some unnecessary over specification that gets in the way extensibility. > > 3. If we can get to a uniform [[Class]] mechanism, maybe an > alternative to various ad-hoc isX attributes would be a generic > classof operator? What is it you want to classify? What is a "class"? There is an infinite variety of ways that ECMAScript objects might be classified. No single one of them is universal. The built-in objects can present some exemplar classification patterns. But the built-ins actually represent a very small set of objects and use cases. We need to be careful about over generalizing from that small sample. > > 4. What about proxies? Is the idea that proxies can *never* emulate > any behaviour that relies on a specific [[Class]]? For example, I > cannot proxy a name. Also, new classes can only be introduced by the > spec. Another reason way I'm eliminating [[Class]]. Also see https://spreadsheets.google.com/spreadsheet/ccc?key=0Ak51JfLL8QLYdFRCOXBRczJfRzNJSEk2eXptQ3BzalE&hl=en_US I may be getting redundant, but the internal classification schemes used by the specification are not a real class hierarchy with any rules regarding their formulation definition. There are a number of different uses of object classification within the spec. (from the google doc referenced in item 2 above): Among them, the object classifications are used for various purposes within the specification including: • Explicit data parametrization of built-in functions based upon object “type”. For example, Object.prototype.toString. • Explicit behavioral parametrization of built-in functions based upon object “type”. For example, Array.prototype.concat. • Explicit behavioral parametrization of language features based upon the object “type” of operands. For example, the delete operator’s use of the [[Delete]] internal method. • Association of private runtime state with specific object instances where the state is used by various specification algorithms. For example, the [[Prototype]] internal property. • Association of abstracted private state with specific object instances where the actual runtime state space is an implementation detail. For example, the [[Scope]] and [[Code]] internal properties of function objects. • Association of abstracted private state with specific object categories where the state is only used for specification purposes and need not actually exists at runtime. For example, the [[FormalParameters]] internal property of function objects. • Specifying a dependency between private runtime state of specific object instances and specific built-in methods that use that state. Date methods that depend upon the [[PrimitiveValue]] property. • Specifying a dependency between object type specific internal behaviors and specific built-in methods that use those behaviors. For example, String.prototype.split method’s use of RegExp [[Match]] internal method. > > 5. What are the conventions by which the library distinguishes between > "regular" object properties and operations, and meta (reflective) > ones? It seems to me that part of the confusion(?) in the discussion > is that the current design makes no real distinction. I think it is > important, though, since e.g. proxies should be able to trap regular > operations, but not reflective ones (otherwise, e.g. isProxy wouldn't > make sense). Also, modern reflective patterns like mirrors make the > point that no reflective method should be on the reflected object > itself. This is what we are in the process of sorting out. The ES spec. (and language) wasn't originally designed from that perspective but I think we can move it there. allen
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
