comments on April draft
david at davidflanagan.com
Fri May 8 22:25:06 PDT 2009
Allen Wirfs-Brock wrote:
> I had another point I wanted to share, given that I imagine that you may write about this someday :-)
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
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.)
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.
>> -----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.
>> es5-discuss mailing list
>> es5-discuss at mozilla.org
More information about the es5-discuss