comments on April draft

David Flanagan david at davidflanagan.com
Fri May 8 22:25:06 PDT 2009


Allen Wirfs-Brock wrote:
> David,
> 
> I had another point I wanted to share, given that I imagine that you may write about this someday :-)
> 
> These api's were designed such that if object literals are used to describe properties it should be fairly easy for JavaScript compilers to statically recognize them and to potentially optimize object construction or object representation based upon compile time analysis of the descriptors. 

That's interesting.  Would such a compile time analysis be easier or 
harder if property descriptors usually looked like "new 
Object.Property(...)" rather than simple object literals?  (Assuming 
Object.Property was not itself writable).

That's just musing, however, not an argument for something like this. 
The piece of my original post that David-Sarah quoted and commented on 
was about API to assist with creating properties, and this is not 
something I feel strongly about.

I feel a little more strongly about the (probably less-common) case of 
reading property descriptors with Object.getOwnPropertyDescriptor(). 
This method returns a generic object, and I thought it might be nice if 
the object had a [[Class]] property and a prototype with a toString() 
method.  Along the same lines, it would be nice if there was a 
constructor (call it Object.Property) so that instanceof could be used 
on these objects.  Perhaps the strongest argument for giving the return 
type of getOwnPropertyDescriptor a name is that it becomes easier to 
document--instead of being an anonymous object described in an anonymous 
paragraph on the getOwnPropertyDescriptor() reference page, it gets its 
own entry in the reference manual!

The augmented array returned by RegExp.exec() is the only other case I 
can think of offhand in which ES returns a value of unnamed type like 
this.

Anyway, that is where my argument for more API here originated--I'd just 
like it if the type could have a name.  The mention of factories like 
Object.Property.constant() was just tacked on.  (I do think, though, 
that the spec could be simplified a bit by defining a public 
Object.Property type and ditching the internal PropertyDescriptor type 
and the related conversion functions.)

	David

  This is particularly true of the Object.defineProperties and 
Object.create functions that might reasonably be used to define complete 
objects. It's much less likely that a compiler would be able to do such 
an analysis in the presence of descriptors that are returned from 
library calls.  So, if a developer wants to maximize optimization 
opportunities it would be a good idea to, whenever possible, express 
property descriptors explicitly as object literals.
> 
> Note that I'm not aware of any implementations that are currently being built to take advantage of this opportunity, but given the current emphasis on performance I won't be surprised to see it happen. But it probably won't help if standard practice becomes to hide property descriptor construction behind framework provided abstractions.
> 
> Allen 
> 
>> -----Original Message-----
>> From: es5-discuss-bounces at mozilla.org [mailto:es5-discuss-
>> bounces at mozilla.org] On Behalf Of Brendan Eich
>> Sent: Friday, May 08, 2009 7:28 PM
>> To: david at davidflanagan.com
>> Cc: es5-discuss at mozilla.org
>> Subject: Re: comments on April draft
>>
>> On May 8, 2009, at 4:43 PM, david at davidflanagan.com wrote:
>>
>>> Okay, so the example wasn't well chosen...  And I know that this was
>>> discussed at length.  I have no intention of trying to revive a dead
>>> horse, but I did want to ask whether it had been decided that the best
>>> public representation of property descriptors was as a generic
>>> object with
>>> no associated API.
>> The API is the object, to channel McLuhan ;-).
>>
>> I had the same reaction at first, but in lieu of named parameters, and
>> so long as users don't preempt future property names that might be
>> standardized, this API is short enough and sufficient if not most
>> concise. Sure, shorter helpers can be invented, and should be.
>> Probably not by Ecma TC39 at this point, though.
>>
>> I've been re-reading the history of C and its standard library. We
>> have a long way to go, and we lack the single-source control that ken,
>> dmr, et al. had at Bell Labs. If we add the right primitives, the
>> library authors will cope. To help library adoption, browsers can pre-
>> cache or otherwise accelerate libraries. Ecma should not prematurely
>> standardize too much, though, and Object.defineProperty seems better
>> in this light than a number of subsets of exposed as individual methods.
>>
>> /be
>> _______________________________________________
>> es5-discuss mailing list
>> es5-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es5-discuss
> 
> 



More information about the es5-discuss mailing list