On Jul 15, 2008, at 10:30 PM, Allen Wirfs-Brock wrote:
I’ve up loaded to the wiki a new document titled: “Proposed
ECMAScript 3.1 Static Object Functions: Use Cases and Rationale”
It’s available as both a pdf and as a Word doc file:
http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%
On Jul 16, 2008, at 12:09 AM, Brendan Eich wrote:
On Jul 15, 2008, at 11:50 PM, Brendan Eich wrote:
* getProperty and getProperties seem misnamed in light of common
usage of get, [[Get]], getProperty, etc. all connoting value-
getting, not descriptor-getting. getPropertyDescriptor is a bit
On Jul 16, 2008, at 5:39 AM, Douglas Crockford wrote:
* Did you consider prototype's Object.extend method:
Object.extend = function(destination, source) {
for (var property in source)
destination[property] = source[property];
return destination;
};
Yes we did.
And? The doc gives
Some people yearn hotly for __proto__, preferrably writable if
at all possible, while others point to problems with security
and software privacy.
I get the impression that this could be solved by adding a fourth
flag among the property flags Enumerable, Writable and Flexible.
There might be a
On Jul 16, 2008, at 8:28 AM, Allen Wirfs-Brock wrote:
I didn't specifically respond to that thread because I wasn't aware
of it. I had intended to mention __proto__ as a precedent but it
slipped through the cracks.
No problem. I wanted to point it out so that the rationale doc might
On Jul 16, 2008, at 10:26 AM, Mark S. Miller wrote:
On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich
[EMAIL PROTECTED] wrote:
And? The doc gives rationales for design decisions. What's the
rationale for leaving Object.extend out?
If the document needs to give rationales for leaving out each
Brendan Eich wrote:
That was unclear, sorry. I meant to suggest that lookupProperty is
a shorter alternative to getPropertyDescriptor. Using lookup or
query relieves the need for Descriptor at the end to disambiguate
value- from descriptor-getting. So:
I find inspectProperty() a little
I actually don't expect mere mortal ECMAScript programmers to be confused
with [[get]] as I won't expect them to have ever been exposed to it. Scanning
the rest of the standard ECMAScript objects, the only methods that use a get
prefix seem to be in Date so this may be some potential for a
On Jul 16, 2008, at 10:29 AM, Ingvar von Schoultz wrote:
Some people yearn hotly for __proto__, preferrably writable if
at all possible, while others point to problems with security
and software privacy.
I wrote recently that __proto__ should be viewed as call/cc without
macros for common
On Jul 16, 2008, at 11:35 AM, Allen Wirfs-Brock wrote:
I could live with lookup, although I think it focuses the meaning
on the access process rather than on the result. Another, slightly
longer alternative would be retrieve.
What do you say to Ingvar's suggestion of inspect?
Personally, I don't that the internal [[Prototype]] property should reify as
an actual property of the object. It's really a more fundamental aspect of
objectness than regular properties. From that perspective, if you want to
control access to it, it should probably be done as a flag on the
On Jul 16, 2008, at 11:44 AM, Brendan Eich wrote:
On Jul 16, 2008, at 11:35 AM, Allen Wirfs-Brock wrote:
I could live with lookup, although I think it focuses the meaning
on the access process rather than on the result. Another, slightly
longer alternative would be retrieve.
What do you
(I'm not going to get you to take the bait on reify, am I?)
I think I like describe better than inspect for no particularly tangible
reason, although it does have more characters. I generally find the Thesaurus a
useful tool in this process and it turned up depict which is shorter but also
On Jul 16, 2008, at 12:31 PM, Allen Wirfs-Brock wrote:
(I'm not going to get you to take the bait on reify, am I?)
(no way! ;-)
I think I like describe better than inspect for no particularly
tangible reason, although it does have more characters. I generally
find the Thesaurus a
On Wed, Jul 16, 2008 at 1:16 PM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
-Original Message-
From: Brendan Eich [mailto:[EMAIL PROTECTED]
Right now, the best I can come up with is that it should be a relatively
efficient way to test for the existence of a possibly inherited
Allen Wirfs-Brock wrote:
In summary, not providing reflective access to an object's prototype doesn't
really provide any real security, it just makes some useful tasks less
convenient. Reverting to barnyard analogies: the barn door is already wide
open and we're debating an inch wide
Ingvar von Schoultz wrote:
Some people yearn hotly for __proto__, preferrably writable if
at all possible, while others point to problems with security
and software privacy.
I get the impression that this could be solved by adding a fourth
flag among the property flags Enumerable, Writable
On Jul 16, 2008, at 1:41 PM, David Flanagan wrote:
Brendan, I think you were correct when you originally wrote:
lookup : define :: get : put.
I think that lookupProperty is much nicer than describeProperty, since
lookup captures the getter nature of the method in a way that
describe does
The ES3 spec already specifies the specific prototype of each built-in object
and their instances. However, when it comes to implementing built-in objects or
for that matter user defined objects there is nothing that prevents an
implementation from using invisible intermediate prototypes for
Working...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Sayre
Sent: Wednesday, July 16, 2008 2:17 PM
To: Mark S. Miller
Cc: es4-discuss@mozilla.org; [EMAIL PROTECTED]
Subject: Re: ES3.1 Object static methods rationale document
Maybe someone
Just wait, reify may yet end up as the last name standing...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: Wednesday, July 16, 2008 2:27 PM
To: David Flanagan
Cc: es4-discuss@mozilla.org es4-discuss
Subject: Re: ES3.1 Object static
On Jul 16, 2008, at 2:36 PM, Allen Wirfs-Brock wrote:
Just wait, reify may yet end up as the last name standing...
Methods don't reify things, the language definition does. Property
descriptors are reified in ES3.1 whether or not you ever call the
method.
I think getPropertyDescriptor is
As far as I can recall, we didn't discuss a specific formulation that
corresponds to Object.extend but we have considered (and arguably provided)
pretty much equivalent functionality in our proposal. I assume that at least
Doug, Adam, or Kris were specifically aware of Object.extend and would
On Jul 16, 2008, at 4:10 PM, Allen Wirfs-Brock wrote:
The most common use case seems to be the one where the target object
is a newly instantiated object without any properties of its own.
That use case (at least for variants of extend that only take a
single source object) is most
Brendan Eich wrote:
There's no point in Visible if the property could be deleted
altogether. What would be the difference?
Oops! Sorry! Lacking low-level insight I didn't think of that.
So my idea has no bearing at all on the inherent problems, much
less solved them. Too bad.
That's not
Although I agree that brevity isn't very important here, still
here's a shorter variation on the same names:
Object.getDescriptor (MyObject, MyName);
Object.setDescriptor (MyObject, MyName, {enumerable: false});
Ingvar
Maciej Stachowiak wrote:
On Jul 16, 2008, at 2:36 PM, Allen
Object.clone is really just what is sometimes called a shallow copy. I would
expect it to be most commonly used to make copies of objects that are mostly
statefull, not for moving behavior around.
If you have one or more mix-ins that you want to directly add to a objects, I
would use
2008/7/15 Allen Wirfs-Brock [EMAIL PROTECTED]:
I've up loaded to the wiki a new document titled: Proposed ECMAScript
3.1
Static Object Functions: Use Cases and Rationale
A couple of questions for you:
My first question: How does an ES3.1 sealed object relate to fixtures?
__| ES
On Wed, Jul 16, 2008 at 2:17 PM, Robert Sayre [EMAIL PROTECTED] wrote:
Maybe someone could just give the rationale for leaving out Object.extend?
Douglas Crockford wrote that it was considered, but I'm confused since
it looks like you haven't even seen a proposal, and didn't participate
in
Arguably, some of the need for direct prototype access is
alleviated by providing the clone method. However, there are still
plenty of other situations where it is useful.
I observe that __proto__ in SpiderMonkey- and Rhino-based JS is
mostly used for cases covered by Object.create, with a
30 matches
Mail list logo
