subject:"using Private name objects for declarative property definition."

On Jul 12, 2011, at 2:54 AM, Andreas Rossberg wrote:

 On 9 July 2011 17:48, Brendan Eich bren...@mozilla.com wrote:
 
 Adding names as a distinct reference and typeof type, extending
 WeakMap to have as its key type (object | name), adds complexity
 compared to subsuming name under object.
 
 It seems to me that you are merely shifting the additional complexity
 from one place to another: either weak maps must be able to handle
 (object + name) for keys (instead of just object), or objects must
 handle (string + object * isName) as property names (instead of just
 string + name).

Quite right. This was a part of ECMA-357, E4X, which we have suppported in 
SpiderMonkey starting in late 2004. It was a part of ES4 as well.

On the other hand, there's no free lunch for private names having a new typeof 
type: name. They cannot be strings, so the VM's property lookup and 
identifier-handling code paths all need a wider type. True, they *could* be 
UUIDs in strings that have a tag bit set to prevent forgery, but that's not a 
likely implementation.

So given that id types and lookup code paths have to change anyway, this seems 
more of a wash than you suggest. Not a total wash, but not a clear with for new 
typeof-type name.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

2011-07-12 Thread Claus Reinke

I think there is a (usually unstated) desire to also test for 
ES.next features that may also start to show up as extensions 
to ES5 level implementations. For example, generators in 
Firefox. You can't depend upon modules in such situations.


For me, the issue is that ES engines tend to implement new 
language versions gradually (currently, still not everyone 
implementing ES5, yet some providing experimental features 
beyond ES5). That practice is good (gets useful features out

there faster) and it matches the ES proposal wiki organization
but JS language versioning on the web is not yet as modular
(see the other thread for generators example, url below).

I tend to think about language feature pragmas as a solution, 
but that is because I've seen that approach work in practice 
elsewhere. The idea of using ES/next modules to manage 
dependencies on language features is new, so I'm not sure 
it would work as well. It depends on two assumptions:


   - ES/next modules need to be the first ES/next feature to 
   be implemented, so that the other features can be
   versioned using modules; 

   that is, Firefox generators would only be available 
   through modular versioning after adding modules


   - dependencies on language.feature modules have to
   be treated specially, to get useful error messages:
   usually, module dependencies are looked into after
   parsing, which is too late to complain about features
   that are not yet supported (I don't know how this
   interacts with transitive dependencies - might render
   the idea unworkable..)

In other words, it is an ad-hoc idea about using module
dependencies as language version pragmas, without having
to add pragma syntax. It does have the advantage that
modules have dependency management and early errors
as part of their feature set already.

The thread with subject Design principles for extending 
ES object abstractions got into this, and I *thikn* (I can't 
be sure because he hasn't replied yet) Luke Hoban, Dave 
Herman, and I were kinda/sorta agreeing that the old 
scripts (ES5 and below) need just one API entry point: 
SystemLoader as a global property (I misspelled it 
Object.ModuleLoader in my reply to Luke).


Once old script has object-detected its way to joy via 
SystemLoader, it can load built-in ES6+ libraries such 
as @name and @iter.


Thanks. My own single-message thread is here:

   feature-based and compartment-based language versioning
   https://mail.mozilla.org/pipermail/es-discuss/2011-July/015755.html


From some of the messages in your thread it seems you

have found yet another variation on mixing versions: using
ES/next functionality while sticking to ES5 syntax (imperative
access to some syntax-based declarative ES/next features).

The API for module detection is under development, but it 
would allow both synchronous testing for a built-in or 
already-loaded MRL, and an async form for loading from 
an MRL over the 'net.


Given this (forgive the lack of complete specs, but it's 
enough, I claim), why do we need anything more for 
future-friendly feature detection?


1. so that we can write code that wants to be ES/next,
   and get early failures with good error messages if that
   code tries to load on an engine that does not implement
   all ES/next features the code depends on. 


   (not parse error at 'yield' but this engine does not
 implement generators yet, sorry)

2. so that we can write code that only depends on some
   ES/next features, and enable engines to figure out
   early if they are able to load and run this code, based 
   on their partially implemented ES/next feature set.


   (if code depends only on generators, current Firefox
   may be able to run it, but we can't specify a dependency
   on only that feature)

3. so that we can selectively enable experimental language
   features, which will continue to be implemented prior to
   standardization, even after ES/next.

   (if code depends on generators, but should not be used in
   combination with some of the other experimental features
   in Firefox, we cannot specify such a selection at the moment)

4. So that coders can document their language feature
   dependencies in their source code (as page scripting is
   replaced by JS applications, and script files are replaced
   by modules).

Claus

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

On Jul 12, 2011, at 7:43 AM, Brendan Eich wrote:

 On the other hand, there's no free lunch for private names having a new 
 typeof type: name. They cannot be strings, so the VM's property lookup and 
 identifier-handling code paths all need a wider type. True, they *could* be 
 UUIDs in strings that have a tag bit set to prevent forgery, but that's not a 
 likely implementation.
 
 So given that id types and lookup code paths have to change anyway, this 
 seems more of a wash than you suggest. Not a total wash, but not a clear with 
 for new typeof-type name.

Er, not a clear win

Another point about implementations: any that perform at all well already use a 
sum type for their internal property id representation, to accomodate int or 
uint *or* string. Adding another arm to that discriminated union is not a huge 
amount of work, in our experience.

For JavaScriptCore, Oliver has argued that internal to the engine, keeping id 
uncoerced as an arbitrary value, until late or deep in the layering, is not 
troublesome and could allow better true array or vector indexing semantics, 
e.g. via proxies.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

2011-07-12 Thread Allen Wirfs-Brock

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_USauthkey=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

Re: using Private name objects for declarative property definition.

Allen, thanks for replying -- I ran out of time this morning. A few comments on 
top of yours.

On Jul 12, 2011, at 10:18 AM, Allen Wirfs-Brock wrote:

 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

Not only that (I argued in my reply), but engines do already tag identifier 
types. Indexing does not use strings 0, 1, etc., even interned strings, in 
engines that aspire to be fast. Such (interned) strings must of course be 
observably equivalent to 0, 1, etc. when used as indexes and preserved as 
type-tagged integer domain property identifiers.


 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.

Just to amplify Allen's reply, we are working on dom.js 
(https://github.com/andreasgal/dom.js), the self-hosted DOM. Per its specs, it 
must be able in some future JS edition to configure the class name reported 
by Object.prototype.toString.call(x, 8, -1).


 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.

The typeof distinction is among primitive types with by-value semantics (null, 
undefined, boolean, number, string) and object, which as discussed recently has 
by-reference semantics, observable because objects are in general mutable.

Among the objects, there are many and non-hierarchically-related classification 
schemes, as Allen reminds us (worth doing to avoid making brittle, crappy, 
tyrannical nominal hierarchies :-/). 

There isn't much nominal here in an untyped language. Perhaps we should use 
branding or trademarking, but when I use nominal in connection with JS I 
mean the same thing: certain built-ins have internal [[Class]] properties which 
not only contribute to Object.prototype.toString's result, the [[Class]] values 
are checked aggressively in built-in methods of these objects, such that the 
methods cannot in general be invoked on objects with other [[Class]] values.

In engine implementations, C++ nominal types are often used, but the JS 
dispatching machinery does not reflect via C++ RTTI or any such thing. Instead, 
something corresponding to [[Class]] is compared to a known singleton, to 
enforce that these non-generic methods are called on the correct type of 
|this|.

To sum up, typeof is for value or primitive vs. object type identification. 
When typeof x === object, x may then be classified in many ways. As a rule, 
and I believe the committee agrees on this, we wish built-ins to be generic 
where practical for implementations to unify representations so as to avoid the 
[[Class]]-equivalent nominal type tag, AKA brand or trademark, test.

A proposal for Harmony gets into surfacing branding in the language:

http://wiki.ecmascript.org/doku.php?id=strawman:trademarks

This didn't make ES.next.

(To repeat a minor comment I gave at the May TC39 meeting, prefigured above, I 
hope we can try to use one word, ideally as short as brand or branding, for 
this nominal type tag idea.)


 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.

However, as my discussion with Allen brought out (I

Re: using Private name objects for declarative property definition.

On Jul 12, 2011, at 11:08 AM, Brendan Eich wrote:

 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.
 
 Definitely! I was in a big rush. I recall putting in primitive types 
 (something I've repented at leisure) for two reasons: (1) be like Java (this 
 wasn't just superficial, we were planning the JS/Java bridge, LiveConnect, 
 even from the start in 1995); (2) ease of implementation (arguably I was 
 biasing toward a certain kind of implementation, but it was what I knew how 
 to do fast: fat discriminated union value types, hardcoded arithmetic for the 
 NUMBER discriminant).
 
 For functions, I made a distinct typeof result so that users could determine 
 callability (remember, there was no try/catch/finally in JS1 and anyway, try 
 around a call attempt is too heavyweight).
 
 Among objects apart from functions, I created the prototype.constructor 
 back-link but otherwise left it up to object implementors to come up with 
 classification schemes.

A bit more on the history of reflective facilities added at the base layer:

For JS1 there was zero time to do proper mirrors-style reflective APIs. Economy 
of implementation and expression, plus the utility of objects as hashes, led me 
to make o[e] evaluate e into a result and equate it to a string property name. 
Even in the first implementation, which had some goofy bugs, I int-specialized 
for speed. From AWK (capitalized like a fanboy, after its creators' surname 
initials) I copied for-in as the matching way of enumerating the keys in the 
object-as-hash.

So at base level, one can reflect on what other languages do not disclose 
without mirrors: the names of properties and, given any expression, the value 
of a property named by the string conversion of the result of evaluating that 
expression.

ES3 added in, instanceof (we've talked about how this went wrong in the 
face of multiple globals), and a paltry (six, IIRC) Object.prototype reflective 
methods, some of which seem misdesigned (e.g. propertyIsEnumerable does not 
have own in its name but does not look up the proto chain). This was just 
shortest-path evolution in TC39 TG1, mostly, although I seem to recall 
prototyping in in SpiderMonkey before ES3 was far along.

Allen's work with mirrors shows how rich and multifarious the reflection API 
world can be. This is good work and we need more of it. I don't think we should 
prematurely standardize mirror-style reflective APIs. We do need to correct 
course on reflective and other API design path missteps where we can.

Waldemar made this point about standards processes: they can cycle faster but 
create path dependencies and enshrine mistakes, painting the language into a 
corner. Cycling too slow is bad too, obviously -- we have been there and done 
that (it's why we at Mozilla added so many things like getters and setters, 
__proto__, Array extras back during the dark ages -- we had no choice with a 
monopoly shutdown of the standards process, and taking that lying down is not 
good in itself or obviously better than making de-facto standards).

Cycling at a pace that fits the Ecma-ISO protocols can work but leaves us with 
mistakes small (we hope) enough to live with, but sometimes worth fixing (we 
should consider each such potential mistake). I know Allen feels this regarding 
Object.create, specifically the property descriptor attribute defaults and 
consequent verbosity when describing typical properties. I feel it of course 
over all the mistakes in most of the language that I've created or had a hand 
in (or where I took time off to found mozilla.org, and did not help ES3). I'm 
not guilty at this advanced age, just resolved to fix what can be fixed.

Mistakes happen, we need to be careful -- but we aren't going to do anyone any 
favors by sitting and thinking on how to achieve perfection -- so we ought to 
make corrections as we go. Backward compatibility then means some redundancy 
over time. There are much worse problems to have.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

2011-07-11 Thread Andreas Rossberg

On 9 July 2011 14:42, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
 Unlike Names, strings and numbers are forgeable, so if they were
 allowed as keys in WeakMaps, the associated value could never be
 safely collected.  Names, by contrast, have identity.

Of course you are right, and I shouldn't post in the middle of the night.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.


On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:

 On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
 
 
 
 Why not a non-writable,non-enumerable non-configurable data property on 
 Function.prototype.
 
 We're talking about isGenerator, right? There is no Generator constructor, no 
 shadowing opportunity. Function can create a generator if yield occurs in the 
 body string.

Oops, forgot we were talking about isGenerator.  So why not internally defined

const  __generatorProto__ = Object.create(Function.prototype, {isGenerator: 
{value: true}});

and specify that function containing yield are created as if by:
 __generatorProto__ | function (...) {...yield...}

 In other words, generator functions have a different [[Prototype]] than 
regulator functions.

Alternatively, isGenerator could be a method, but that's the the point here.

Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

On Jul 11, 2011, at 9:25 AM, Allen Wirfs-Brock wrote:

 On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:
 
 On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
 
 Why not a non-writable,non-enumerable non-configurable data property on 
 Function.prototype.
 
 We're talking about isGenerator, right? There is no Generator constructor, 
 no shadowing opportunity. Function can create a generator if yield occurs in 
 the body string.
 
 Oops, forgot we were talking about isGenerator.  So why not internally defined
 
 const  __generatorProto__ = Object.create(Function.prototype, {isGenerator: 
 {value: true}});
 
 and specify that function containing yield are created as if by:
 __generatorProto__ | function (...) {...yield...}
 
 In other words, generator functions have a different [[Prototype]] than 
 regulator functions.

There's no point. We haven't ever had a request for this. It requires polluting 
the global object (or some object) with a property (even adding a private name 
requires adding a public property naming the private name object).


 Alternatively, isGenerator could be a method, but that's the the point here.

That's the point we're arguing about, yes.

The method allows object-detection, which helps. It's ad-hoc but web JS has 
versioned itself based on object detection far better than on other, _a priori_ 
grand plans (Accept: headers, e.g.).

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.


On Jul 11, 2011, at 9:32 AM, Brendan Eich wrote:

 On Jul 11, 2011, at 9:25 AM, Allen Wirfs-Brock wrote:
 
 On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:
 
 On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
 
 Why not a non-writable,non-enumerable non-configurable data property on 
 Function.prototype.
 
 We're talking about isGenerator, right? There is no Generator constructor, 
 no shadowing opportunity. Function can create a generator if yield occurs 
 in the body string.
 
 Oops, forgot we were talking about isGenerator.  So why not internally 
 defined
 
 const  __generatorProto__ = Object.create(Function.prototype, {isGenerator: 
 {value: true}});
 
 and specify that function containing yield are created as if by:
__generatorProto__ | function (...) {...yield...}
 
 In other words, generator functions have a different [[Prototype]] than 
 regulator functions.
 
 There's no point. We haven't ever had a request for this. It requires 
 polluting the global object (or some object) with a property (even adding a 
 private name requires adding a public property naming the private name 
 object).


I don't think we or anybody else has really explored the extensibility 
implications of generator functions so it isn't surprising that there have been 
no requests.

Certainly there is no need to add any new globals to support a distinct 
prototype for generator functions. Strictly speaking there wouldn't even have 
to be a property on Function to access it as it would be a built-in object that 
is accessed internally when a generator is created.  However, I do think it 
would be useful make it accessible via something like 
Function.generatorPrototype.   I don't see that adding such a property as 
undesirable pollution.



 
 
 Alternatively, isGenerator could be a method, but that's the the point here.
 
 That's the point we're arguing about, yes.

I think that the factoring of the prototype hierarchy is largely distinct issue 
but, yes, there is some overlap in that a use of a data property for this 
particular tagging requires a separate prototype object for generators. 

 
 The method allows object-detection, which helps. It's ad-hoc but web JS has 
 versioned itself based on object detection far better than on other, _a 
 priori_ grand plans (Accept: headers, e.g.).

Function.generatorPrototype as described above would also support 
object-detection.

In general, how far to you think we can push a all new features have to be 
object-detectable requirement.  Do we need to be able to object-detect |.  
How about rest and spread, or de-structuring?  We are going to use non-eval 
detectability as a ECMAScript extension design criteria then maybe we do need a 
less ad-hoc scheme for feature detection.  It wouldn't have to be all that 
grand...

allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

On Jul 11, 2011, at 10:25 AM, Allen Wirfs-Brock wrote:

 I don't think we or anybody else has really explored the extensibility 
 implications of generator functions so it isn't surprising that there have 
 been no requests.

We certainly have explored generators (extensibility is not a good in itself) 
since 2006. Multiple libraries on github use them.


 Certainly there is no need to add any new globals to support a distinct 
 prototype for generator functions. Strictly speaking there wouldn't even have 
 to be a property on Function to access it as it would be a built-in object 
 that is accessed internally when a generator is created.  However, I do think 
 it would be useful make it accessible via something like 
 Function.generatorPrototype.   I don't see that adding such a property as 
 undesirable pollution.

We're still trying to get isFoo conventions in order. Why add another (first-of 
or one-off) built-in prototype convention?

I'm going to stick with YAGNI and when in doubt, leave it out. Generators win 
to the extent that they are functions with the least shallow continuation 
semantics on top that work.


 The method allows object-detection, which helps. It's ad-hoc but web JS has 
 versioned itself based on object detection far better than on other, _a 
 priori_ grand plans (Accept: headers, e.g.).
 
 Function.generatorPrototype as described above would also support 
 object-detection.
 
 In general, how far to you think we can push a all new features have to be 
 object-detectable requirement.  Do we need to be able to object-detect |.

It's easy to go overboard. Developers do not detect at fine grain to handle 
insane or never-shipped combinations. The combinatorics explode, and reality is 
that browsers support feature cohorts that are fairly chunky.


  How about rest and spread, or de-structuring?  We are going to use non-eval 
 detectability as a ECMAScript extension design criteria then maybe we do need 
 a less ad-hoc scheme for feature detection.  It wouldn't have to be all that 
 grand...

Even less grand ones such as the DOM's 
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMFeatures) are failures.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

2011-07-11 Thread Claus Reinke

How about rest and spread, or de-structuring?  We are 
going to use non-eval detectability as a ECMAScript 
extension design criteria then maybe we do need a less 
ad-hoc scheme for feature detection.  It wouldn't have 
to be all that grand...


Even less grand ones such as the DOM's 
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMFeatures) 
are failures.


Just noticed this hidden sub-thread, which seems to be related
to my attempt to start a thread on modular versioning. How 
about the following attempt at least-grandness?-)


- have a built-in module hierarchy 'language', with submodules
   for each new ES/next feature that is implemented in the
   current engine (language.destructuring, language.generators, ..)

- code that relies on one of those features can try to import the
   language.feature module, and will be rejected early if that
   feature module isn't available

- there could be collective modules corresponding to language
   versions (ES5, JS1.7, ES/next, ..), which behave as if they
   imported the language feature modules corresponding to
   that language version

- this would suggest that ES/next modules ought to be the
   first ES/next feature to be implemented, to support versioned
   addition of the remaining ES/next features; but since modules
   already need to manage dependencies, there is no need to
   replicate that functionality for language features

Makes sense?
Claus

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.


On Jul 11, 2011, at 10:41 AM, Brendan Eich wrote:

 On Jul 11, 2011, at 10:25 AM, Allen Wirfs-Brock wrote:
 
 
 Certainly there is no need to add any new globals to support a distinct 
 prototype for generator functions. Strictly speaking there wouldn't even 
 have to be a property on Function to access it as it would be a built-in 
 object that is accessed internally when a generator is created.  However, I 
 do think it would be useful make it accessible via something like 
 Function.generatorPrototype.   I don't see that adding such a property as 
 undesirable pollution.
 
 We're still trying to get isFoo conventions in order. Why add another 
 (first-of or one-off) built-in prototype convention?
 
 I'm going to stick with YAGNI and when in doubt, leave it out. Generators win 
 to the extent that they are functions with the least shallow continuation 
 semantics on top that work.

Let's try to back out of the brambles a bit:

On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:

 On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:

 

 yes.  I wonder if isArray and isInteger are different kinds of 
 categorizations (class based vs value based) that perhaps should have 
 distinct naming conventions.

 

 The isFoo predicate convention is used variously in other languages. Kind of 
 like foop in Lisps. I would not tax name length just to distinguish these 
 cases, or others (ontology fanatics will soon be splitting sub-cases of 
 value-based).


isGenerator is essentially a value test rather than class-like categorization.  
Methods work well for this because a method can dynamically inspect the value 
being tested in order to make the determination.

However, methods are less desirable for class-like categorization because they 
require an existence predicated call (f.isFoo  f.isFoo()) which potentially 
leads to monkey patching Object.prototype (Object.prototype.isFoo = 
function(){return false}).  A truthy data property is a plausable alternative 
that avoids the need for monkey patching, but it doesn't work for value tests.

If a value tests can be recast as a class-like categorization then the data 
property approach works for it. Using an alternative prototype for all values 
in a subclass (eg all generators) seems like a technique that might be 
plausible in situations like this.  It is essentially just a way to factor out 
of each generator the storage of the true value for the isGenerator property.  
It doesn't require the exposure of a separate Generator constructor. 

We are trying to generalize to a pattern to apply to all (or at least most 
isFoo) situations.  Here is what we seem to have observed so far:

A isFoo method works well for value classification for situations where you 
will generally  already know the class of the value.
A independent classification function (perhaps hung from a constructor) may be 
a good solution when value classification will generally be done in situations 
where the class of the value is not predetermined.
A truthy isFoo data property works will for class-like categorization as long 
as all values that share the same prototype are considered members of the same 
category.


Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.


On Jul 11, 2011, at 11:50 AM, Claus Reinke wrote:

 How about rest and spread, or de-structuring?  We are going to use non-eval 
 detectability as a ECMAScript extension design criteria then maybe we do 
 need a less ad-hoc scheme for feature detection.  It wouldn't have to be 
 all that grand...
 Even less grand ones such as the DOM's 
 (http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMFeatures) are failures.
 
 Just noticed this hidden sub-thread, which seems to be related
 to my attempt to start a thread on modular versioning. How about the 
 following attempt at least-grandness?-)
 
 - have a built-in module hierarchy 'language', with submodules
   for each new ES/next feature that is implemented in the
   current engine (language.destructuring, language.generators, ..)
 
 - code that relies on one of those features can try to import the
   language.feature module, and will be rejected early if that
   feature module isn't available
 
 - there could be collective modules corresponding to language
   versions (ES5, JS1.7, ES/next, ..), which behave as if they
   imported the language feature modules corresponding to
   that language version
 
 - this would suggest that ES/next modules ought to be the
   first ES/next feature to be implemented, to support versioned
   addition of the remaining ES/next features; but since modules
   already need to manage dependencies, there is no need to
   replicate that functionality for language features
 
 Makes sense?
 Claus

I think there is a (usually unstated) desire to also test for ES.next features 
that may also start to show up as extensions to ES5 level implementations. 
For example, generators in Firefox. You can't depend upon modules in such 
situations.

Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

On Jul 11, 2011, at 12:46 PM, Allen Wirfs-Brock wrote:

 I think there is a (usually unstated) desire to also test for ES.next 
 features that may also start to show up as extensions to ES5 level 
 implementations. For example, generators in Firefox. You can't depend upon 
 modules in such situations.

The thread with subject Design principles for extending ES object 
abstractions got into this, and I *thikn* (I can't be sure because he hasn't 
replied yet) Luke Hoban, Dave Herman, and I were kinda/sorta agreeing that the 
old scripts (ES5 and below) need just one API entry point: SystemLoader as a 
global property (I misspelled it Object.ModuleLoader in my reply to Luke).

Once old script has object-detected its way to joy via SystemLoader, it can 
load built-in ES6+ libraries such as @name and @iter.

The API for module detection is under development, but it would allow both 
synchronous testing for a built-in or already-loaded MRL, and an async form for 
loading from an MRL over the 'net.

Given this (forgive the lack of complete specs, but it's enough, I claim), why 
do we need anything more for future-friendly feature detection?

/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

On Jul 11, 2011, at 12:40 PM, Allen Wirfs-Brock wrote:

 isGenerator is essentially a value test rather than class-like 
 categorization.  Methods work well for this because a method can dynamically 
 inspect the value being tested in order to make the determination.

I'm not so sure about this now. I was just reviewing with Dave how the design 
evolved. We had Function.isGenerator, analogous to Array.isArray. For taskjs, 
Dave had thought he had a use-case where the code has a function and wants to 
know whether it's a generator. It turned out (IIUC) that what he really wanted 
(this will warm your heart) was simply the duck-type does it implement the 
iterator protocol test.

On the other hand, code that wants to ask is this *value* a generator? may 
not have a-priori knowledge that the value is a function, so a class method 
such as Function.isGenerator wins.

Indeed Array.isArray, apart from being named as if it were a class method just 
to avoid polluting the global (or some other) object, is a predicate function 
-- not  a method. You can't know that you have an Array instance, never mind an 
object-type (typeof sense) value, all the time. If you don't know whether x is 
an array or even an object as opposed to a primitive, just call 
Array.isArray(x).

This strongly suggests to me that we want predicate functions. For the @name 
built-in module, isName is one such. There's no need to stick that into a 
class object just to avoid name pollution, since the module lets the importer 
name the import.

To rehash a subtle point again: our Function.prototype.isGenerator method is 
particular nasty if a user knows Array.isArray and expects 
Function.isGenerator(x) to test whether x is a generator (or any non-generator, 
whether function or not) value. That expression actually evaluates equivalently 
to Function.prototype.isGenerator.call(Function, x), and x is ignored -- and 
Function is of course not a generator.

So I think we took the wrong door here. Function.isGenerator by analogy to 
Array.isGenerator, or an isGenerator export from @iter (equivalent 
semantically), is the best way.


 However, methods are less desirable for class-like categorization because 
 they require an existence predicated call (f.isFoo  f.isFoo()) which 
 potentially leads to monkey patching Object.prototype (Object.prototype.isFoo 
 = function(){return false}).  A truthy data property is a plausable 
 alternative that avoids the need for monkey patching, but it doesn't work for 
 value tests.

Only if you know you have an object. If the predicate you need has signature 
any - boolean then you want a function.


 If a value tests can be recast as a class-like categorization then the data 
 property approach works for it.

Right, but you can't recast for any type of value without writing a prior 
typeof conjunct. Or did you mean something else by recast?


 Using an alternative prototype for all values in a subclass (eg all 
 generators) seems like a technique that might be plausible in situations like 
 this.  It is essentially just a way to factor out of each generator the 
 storage of the true value for the isGenerator property.  It doesn't require 
 the exposure of a separate Generator constructor. 

I think this misses the mark. Both Array.isArray in ES5 and 
Function.isGenerator in ES.next are testing nominal type tag. They are not 
testing some ad-hoc boolean tag that is not reliable and that can be forged.


 We are trying to generalize to a pattern to apply to all (or at least most 
 isFoo) situations.  Here is what we seem to have observed so far:
 
 A isFoo method works well for value classification for situations where you 
 will generally  already know the class of the value.

Agreed.


 A independent classification function (perhaps hung from a constructor) may 
 be a good solution when value classification will generally be done in 
 situations where the class of the value is not predetermined.

Agreed.


 A truthy isFoo data property works will for class-like categorization as long 
 as all values that share the same prototype are considered members of the 
 same category.

Disagree for the use-cases you applied this to. ES5 mandates a [[Class]] check 
for Array.isArray, and the impetus there was cross-frame Array classification 
based on nominal really-truly-built-in-Array type tag.

Ditto for any isGenerator worth its name, that is, to the extent that the 
use-case for isGenerator does not simply want to test is it an iterator 
factory, which could be a structural or duck-type test.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

2011-07-11 Thread David Herman

 Adding a non-enumerable Array.prototype method seems doable to me, if the 
 name is clear and not commonly used.
 
 
 We can probably still add Array.prototoype.isArray if that would help to 
 establish the pattern. Document as being preferred over Array.isArray

This doesn't make sense to me. Let's say I have a variable x and it's bound to 
some value but I don't know what. That is, it has the type any. I could check 
to see that it's an object:

typeof x === object

and then that it has an isArray method:

typeof x.isArray === function

but how do I know that this isArray method has the semantics I intend? I could 
check that it's equal to Array.prototype.isArray, but that won't work across 
iframes.

IOW, I can't call x.isArray() to find out what I want it to tell me until I 
already know the information I want it to tell me.

Alternatively, if I expect isArray to be a boolean rather than a predicate, I 
still don't have any way of knowing whether x is of a type that has an entirely 
different semantics for the name isArray. It's anti-modular to claim a 
universal semantics for that name across all possible datatypes in any program 
ever.

These static predicates (which are just glorified module-globals) intuitively 
have the type:

any - boolean:T

(I'm using notation from SamTH's research here.) This means a function that 
takes any value whatsoever and returns a boolean indicating whether the result 
is of the type T. Because they accept the type any, it doesn't make sense to 
put them in an inheritance hierarchy. It makes sense to have them as functions. 
Since globals are out of the question, in the past they've been made into 
statics. But with modules, we can actually make them functions in their 
appropriate modules.

Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

On Jul 11, 2011, at 4:18 PM, Brendan Eich wrote:

 So I think we took the wrong door here. Function.isGenerator by analogy to 
 Array.isGenerator,

... by analogy to Array.isArray, of course.

/be

 or an isGenerator export from @iter (equivalent semantically), is the best 
 way.
 
 
 However, methods are less desirable for class-like categorization because 
 they require an existence predicated call (f.isFoo  f.isFoo()) which 
 potentially leads to monkey patching Object.prototype 
 (Object.prototype.isFoo = function(){return false}).  A truthy data property 
 is a plausable alternative that avoids the need for monkey patching, but it 
 doesn't work for value tests.
 
 Only if you know you have an object. If the predicate you need has signature 
 any - boolean then you want a function.
 
 
 If a value tests can be recast as a class-like categorization then the data 
 property approach works for it.
 
 Right, but you can't recast for any type of value without writing a prior 
 typeof conjunct. Or did you mean something else by recast?
 
 
 Using an alternative prototype for all values in a subclass (eg all 
 generators) seems like a technique that might be plausible in situations 
 like this.  It is essentially just a way to factor out of each generator the 
 storage of the true value for the isGenerator property.  It doesn't require 
 the exposure of a separate Generator constructor. 
 
 I think this misses the mark. Both Array.isArray in ES5 and 
 Function.isGenerator in ES.next are testing nominal type tag. They are not 
 testing some ad-hoc boolean tag that is not reliable and that can be forged.
 
 
 We are trying to generalize to a pattern to apply to all (or at least most 
 isFoo) situations.  Here is what we seem to have observed so far:
 
 A isFoo method works well for value classification for situations where you 
 will generally  already know the class of the value.
 
 Agreed.
 
 
 A independent classification function (perhaps hung from a constructor) may 
 be a good solution when value classification will generally be done in 
 situations where the class of the value is not predetermined.
 
 Agreed.
 
 
 A truthy isFoo data property works will for class-like categorization as 
 long as all values that share the same prototype are considered members of 
 the same category.
 
 Disagree for the use-cases you applied this to. ES5 mandates a [[Class]] 
 check for Array.isArray, and the impetus there was cross-frame Array 
 classification based on nominal really-truly-built-in-Array type tag.
 
 Ditto for any isGenerator worth its name, that is, to the extent that the 
 use-case for isGenerator does not simply want to test is it an iterator 
 factory, which could be a structural or duck-type test.
 
 /be
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.

2011-07-11 Thread David Herman

 I'm not so sure about this now. I was just reviewing with Dave how the design 
 evolved. We had Function.isGenerator, analogous to Array.isArray. For taskjs, 
 Dave had thought he had a use-case where the code has a function and wants to 
 know whether it's a generator. It turned out (IIUC) that what he really 
 wanted (this will warm your heart) was simply the duck-type does it 
 implement the iterator protocol test.

Right-- it was a poor initial implementation decision on my part; I shouldn't 
have done any test at all.

JJB had a different use case: for Firebug, he wanted the ability to check 
before calling a function whether it was going to have a different control-flow 
semantics. IOW, he wanted to be able to reliably reflect on values.

 On the other hand, code that wants to ask is this *value* a generator? may 
 not have a-priori knowledge that the value is a function, so a class method 
 such as Function.isGenerator wins.

Yeah, I think it's generally more convenient for type-distinguishing predicates 
to have input type 'any', so that clients don't have to do any other tests 
beforehand. That way, you can always simply do

isGenerator(x)

instead of

typeof x === function  x.isGenerator()

without knowing anything about x beforehand.

 So I think we took the wrong door here. Function.isGenerator by analogy to 
 Array.isArray, or an isGenerator export from @iter (equivalent 
 semantically), is the best way.

I agree.

Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.


On Jul 11, 2011, at 4:19 PM, David Herman wrote:

 Adding a non-enumerable Array.prototype method seems doable to me, if the 
 name is clear and not commonly used.
 
 
 We can probably still add Array.prototoype.isArray if that would help to 
 establish the pattern. Document as being preferred over Array.isArray
 
 This doesn't make sense to me. Let's say I have a variable x and it's bound 
 to some value but I don't know what. That is, it has the type any. I could 
 check to see that it's an object:
 
typeof x === object
 
 and then that it has an isArray method:
 
typeof x.isArray === function
 
 but how do I know that this isArray method has the semantics I intend? I 
 could check that it's equal to Array.prototype.isArray, but that won't work 
 across iframes.
 
 IOW, I can't call x.isArray() to find out what I want it to tell me until I 
 already know the information I want it to tell me.
 
 Alternatively, if I expect isArray to be a boolean rather than a predicate, I 
 still don't have any way of knowing whether x is of a type that has an 
 entirely different semantics for the name isArray. It's anti-modular to 
 claim a universal semantics for that name across all possible datatypes in 
 any program ever.

In fact, this is exactly how polymorphic reuse and extensibility occurs in 
dynamically typed OO languages. And, for the most part it actually works even 
in quite complete programs. You aren't assigning a universal semantics to a 
name in all programs but you are asserting a contextual semantics for this 
particular program. Even within a single program, different objects can assign 
complete different and unrelated meanings to isFoo as long as the different 
objects never need to both be processed by common code that does a isFoo test.

In practice, if such objects invalidly cross paths, any wrong answers from 
classification methods are usually easy to spot because they quickly lead to 
other dynamically detected failures.  Once that occurs  there typically are 
easily observable differences between the objects that make the problem easy to 
find.

Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: using Private name objects for declarative property definition.


On Jul 11, 2011, at 4:18 PM, Brendan Eich wrote:

 On Jul 11, 2011, at 12:40 PM, Allen Wirfs-Brock wrote:
 
 isGenerator is essentially a value test rather than class-like 
 categorization.  Methods work well for this because a method can dynamically 
 inspect the value being tested in order to make the determination.
 
 I'm not so sure about this now. I was just reviewing with Dave how the design 
 evolved. We had Function.isGenerator, analogous to Array.isArray. For taskjs, 
 Dave had thought he had a use-case where the code has a function and wants to 
 know whether it's a generator. It turned out (IIUC) that what he really 
 wanted (this will warm your heart) was simply the duck-type does it 
 implement the iterator protocol test.
 
 On the other hand, code that wants to ask is this *value* a generator? may 
 not have a-priori knowledge that the value is a function, so a class method 
 such as Function.isGenerator wins.
 
 Indeed Array.isArray, apart from being named as if it were a class method 
 just to avoid polluting the global (or some other) object, is a predicate 
 function -- not  a method. You can't know that you have an Array instance, 
 never mind an object-type (typeof sense) value, all the time. If you don't 
 know whether x is an array or even an object as opposed to a primitive, just 
 call Array.isArray(x).
 
 This strongly suggests to me that we want predicate functions. For the 
 @name built-in module, isName is one such. There's no need to stick that 
 into a class object just to avoid name pollution, since the module lets the 
 importer name the import.
 
 To rehash a subtle point again: our Function.prototype.isGenerator method is 
 particular nasty if a user knows Array.isArray and expects 
 Function.isGenerator(x) to test whether x is a generator (or any 
 non-generator, whether function or not) value. That expression actually 
 evaluates equivalently to Function.prototype.isGenerator.call(Function, x), 
 and x is ignored -- and Function is of course not a generator.
 
 So I think we took the wrong door here. Function.isGenerator by analogy to 
 Array.isGenerator, or an isGenerator export from @iter (equivalent 
 semantically), is the best way.


I was almost sold on this argument, but I see a different issue.  Global 
predicate functions like this aren't extensible.  Array.isArray and 
Function.isGenerator work fine because they are testing deep implementation 
level characteristics of special objects that can not be emulated by JS code 
(at least without proxies, in the case of Array).  However, for pure JS 
classification you want them to be duck-type extensible. It is easy to add a 
new implementation for some category if the category test uses an instance 
property classification property (whether method or data property) and perhaps 
with some monkey patching.   But a single global predicate can't be post facto 
extended to recognize new implementations of the category unless it was built 
with some internal extension mechanism (and any any such mechanism is likely to 
depend upon some per instance property, so that just loops us back to the same 
solution).  I think you already brought this up earlier in this thread when
  you asked how would I extend Array.isArray to recognize a proxy based 
implementation of Array.

 
 
 However, methods are less desirable for class-like categorization because 
 they require an existence predicated call (f.isFoo  f.isFoo()) which 
 potentially leads to monkey patching Object.prototype 
 (Object.prototype.isFoo = function(){return false}).  A truthy data property 
 is a plausable alternative that avoids the need for monkey patching, but it 
 doesn't work for value tests.
 
 Only if you know you have an object. If the predicate you need has signature 
 any - boolean then you want a function.

All values except for null and undefined are automatically coerced to objects 
for property access.  If a value is expected to possibly be null or undefined 
then that probably represents a separate condition and should have a separate 
test.  If null/undefined is not an anticipate value then an exception on the 
property access is probably a fine dynamic error check.

 
 
 If a value tests can be recast as a class-like categorization then the data 
 property approach works for it.
 
 Right, but you can't recast for any type of value without writing a prior 
 typeof conjunct. Or did you mean something else by recast?

No, I don't mean a dynamic type cast.  I meant something like giving generator 
functions a distinct prototype so the isGenerator: true could be factored out 
of the individual instances. 

 
 
 Using an alternative prototype for all values in a subclass (eg all 
 generators) seems like a technique that might be plausible in situations 
 like this.  It is essentially just a way to factor out of each generator the 
 storage of the true value for the isGenerator property.  It doesn't require 
 the exposure of a separate Generator

Re: using Private name objects for declarative property definition.

On Jul 11, 2011, at 5:29 PM, Allen Wirfs-Brock wrote:

 I was almost sold on this argument, but I see a different issue.  Global 
 predicate functions like this aren't extensible.  Array.isArray and 
 Function.isGenerator work fine because they are testing deep implementation 
 level characteristics of special objects that can not be emulated by JS code 
 (at least without proxies, in the case of Array).

True of isName and Proxy.isProxy (neé isTrapping) too.

I agree the duck-typing and class-tag test use-cases are different. I'm pretty 
sure we don't have any standard or proposed isDuck examples, though.


 However, for pure JS classification you want them to be duck-type extensible. 
 It is easy to add a new implementation for some category if the category test 
 uses an instance property classification property (whether method or data 
 property) and perhaps with some monkey patching.   But a single global 
 predicate can't be post facto extended to recognize new implementations of 
 the category unless it was built with some internal extension mechanism (and 
 any any such mechanism is likely to depend upon some per instance property, 
 so that just loops us back to the same solution).

Why switch topics to pure JS classification, though? There are two different 
use-cases here.


  I think you already brought this up earlier in this thread when you asked 
 how would I extend Array.isArray to recognize a proxy based implementation of 
 Array.

I did, but that's not the same case. Array.isArray is not asking a duck- or 
structural-typing question. It really wants all the magic, which can't be 
written down via recursive structural types. If you can make a Proxy instance 
that fools users and passes the Array-Turing-test, great! But then you have to 
reimplement Array.isArray at least -- perhaps even replace all of Array.


 However, methods are less desirable for class-like categorization because 
 they require an existence predicated call (f.isFoo  f.isFoo()) which 
 potentially leads to monkey patching Object.prototype 
 (Object.prototype.isFoo = function(){return false}).  A truthy data 
 property is a plausable alternative that avoids the need for monkey 
 patching, but it doesn't work for value tests.
 
 Only if you know you have an object. If the predicate you need has signature 
 any - boolean then you want a function.
 
 All values except for null and undefined are automatically coerced to objects 
 for property access.

Yes, null and undefined count -- especially since with an unknown value you 
are more likely to have undefined than 42 or foo. Also, nasty host objects.

I don't think close enough, ignore null and undefined cuts it.


  If a value is expected to possibly be null or undefined then that probably 
 represents a separate condition and should have a separate test.

Why?

One can write any - boolean functions. Many built-in operators and functions 
take any type input argument, not only non-null object arguments.

A restriction against null and undefined is arbitrary and it taxes all 
programmers who have to (remember to) write the extra test, instead of taxing 
the implementation to provide the predicate once for all.


  If null/undefined is not an anticipate value then an exception on the 
 property access is probably a fine dynamic error check.

Not for Array.isArray or the other built-ins we're discussing.

We shouldn't make arbitrary judgments against certain use-cases. Sometimes you 
know you have an object (or even a function), and a narrower input type for a 
predicate will do. Other times, you need the widest (any - boolean) predicate. 
And the latter can work in the former cases without trouble. So why insist on 
object.method() with throw on null or undefined?


 If a value tests can be recast as a class-like categorization then the data 
 property approach works for it.
 
 Right, but you can't recast for any type of value without writing a prior 
 typeof conjunct. Or did you mean something else by recast?
 
 No, I don't mean a dynamic type cast.  I meant something like giving 
 generator functions a distinct prototype so the isGenerator: true could be 
 factored out of the individual instances. 

That does not handle the nominal type test you agree is the purpose of 
isGenerator, so I don't know why you're citing this use-case for the other, 
is-a-loose-duck-type case.


 Using an alternative prototype for all values in a subclass (eg all 
 generators) seems like a technique that might be plausible in situations 
 like this.  It is essentially just a way to factor out of each generator 
 the storage of the true value for the isGenerator property.  It doesn't 
 require the exposure of a separate Generator constructor. 
 
 I think this misses the mark. Both Array.isArray in ES5 and 
 Function.isGenerator in ES.next are testing nominal type tag. They are not 
 testing some ad-hoc boolean tag that is not reliable and that can be 
 forged.
 
 I agree.  But we are trying

Re: using Private name objects for declarative property definition.


On Jul 11, 2011, at 6:14 PM, Brendan Eich wrote:

 On Jul 11, 2011, at 5:29 PM, Allen Wirfs-Brock wrote:
 
 However, for pure JS classification you want them to be duck-type 
 extensible. It is easy to add a new implementation for some category if the 
 category test uses an instance property classification property (whether 
 method or data property) and perhaps with some monkey patching.   But a 
 single global predicate can't be post facto extended to recognize new 
 implementations of the category unless it was built with some internal 
 extension mechanism (and any any such mechanism is likely to depend upon 
 some per instance property, so that just loops us back to the same solution).
 
 Why switch topics to pure JS classification, though? There are two different 
 use-cases here.

Well, I thought we were trying to find a pattern that was applicable to both:

On Jul 9, 2011, at 11:19 AM, Allen Wirfs-Brock wrote:

 A consideration here is that whatever conventions we follow sets a precedent 
 for user written code. I don't think we want to encourage the addition of 
 such classification functions to Object or Object.prototype.  So from that 
 perspective Array.isArray, Function.isGenerator, and Proxy.isProxy are better 
 exemplars than Object.isArray, etc.


 Maybe we weren't as user written code normally does define these sorts of 
implementation classifications.  However, the fact it took this long for us 
(well, at least me) to see that probably is a good indication that this 
distinction isn't always an obvious one. 

 
 However, methods are less desirable for class-like categorization because 
 they require an existence predicated call (f.isFoo  f.isFoo()) which 
 potentially leads to monkey patching Object.prototype 
 (Object.prototype.isFoo = function(){return false}).  A truthy data 
 property is a plausable alternative that avoids the need for monkey 
 patching, but it doesn't work for value tests.
 
 Only if you know you have an object. If the predicate you need has 
 signature any - boolean then you want a function.
 
 All values except for null and undefined are automatically coerced to 
 objects for property access.
 
 Yes, null and undefined count -- especially since with an unknown value you 
 are more likely to have undefined than 42 or foo. Also, nasty host objects.
 
 I don't think close enough, ignore null and undefined cuts it.
 
 
 If a value is expected to possibly be null or undefined then that probably 
 represents a separate condition and should have a separate test.
 
 Why?

When used as an explicit marker then there is probably explicit logic to deal 
with whatever the marker represents.  The test for that condition can precede 
any other classification test.

If  they are being used intentionally then as such a marker then property 
accessing dereferencing them is probably an unintended error situation.

 
 One can write any - boolean functions. Many built-in operators and functions 
 take any type input argument, not only non-null object arguments.

Regardless of whether or not that was a wise design choice, it is precedent 
that we do need to consider. 
 
 A restriction against null and undefined is arbitrary and it taxes all 
 programmers who have to (remember to) write the extra test, instead of taxing 
 the implementation to provide the predicate once for all.
 
 
 If null/undefined is not an anticipate value then an exception on the 
 property access is probably a fine dynamic error check.
 
 Not for Array.isArray or the other built-ins we're discussing.
Yes, but since we seem to be circling in predicate functions for those tests 
it's not an issue for them.

 
 We shouldn't make arbitrary judgments against certain use-cases. Sometimes 
 you know you have an object (or even a function), and a narrower input type 
 for a predicate will do. Other times, you need the widest (any - boolean) 
 predicate. And the latter can work in the former cases without trouble. So 
 why insist on object.method() with throw on null or undefined?


Well, this may be a style point that we can't agree on.  I do think, that 
undefined and null are special cases that probably need to be explicitly dealt 
within when their use is intentional.  

 
 
 If a value tests can be recast as a class-like categorization then the 
 data property approach works for it.
 
 Right, but you can't recast for any type of value without writing a prior 
 typeof conjunct. Or did you mean something else by recast?
 
 No, I don't mean a dynamic type cast.  I meant something like giving 
 generator functions a distinct prototype so the isGenerator: true could be 
 factored out of the individual instances. 
 
 That does not handle the nominal type test you agree is the purpose of 
 isGenerator, so I don't know why you're citing this use-case for the other, 
 is-a-loose-duck-type case.

Because I got confused about what problem we were trying to solve.  Also, like 
I said above, the distinction between the two use

Re: using Private name objects for declarative property definition.