of the Object.create function is 1.
-Original Message-
From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 6:21 PM
To: Allen Wirfs-Brock
Cc: es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document
On Fri, Jul 18, 2008 at 2:02 PM, Allen Wirfs-Brock
Subject: RE: ES3.1 Object static methods rationale document
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
Allen Wirfs-Brock wrote:
Object.create's heritage is Doug Crockford's beget function and its primary
purpose is to provide a more direct way to create an object with an
explicitly specified prototype.
I think the name Object.createHeir would clarify its use better.
--
Ingvar von Schoultz
2008/7/18 Allen Wirfs-Brock [EMAIL PROTECTED]:
Collectively,
getOwnProperty,defineProperties/defineProperty,getOwnPropertyNames,getPrototypeOf
are intended to provide all the mechanisms necessary to build any of these
variants to extent or any other model of property manipulation using
: John Resig; es3 x-discuss; es4-discuss@mozilla.org; Mark S. Miller; Robert
Sayre
Subject: Re: ES3.1 Object static methods rationale document
2008/7/18 Allen Wirfs-Brock [EMAIL PROTECTED]:
Collectively,
getOwnProperty,defineProperties/defineProperty,getOwnPropertyNames,getPrototypeOf
On Jul 18, 2008, at 9:02 AM, Allen Wirfs-Brock wrote:
We ultimately concluded that the best way to think about what we
are currently provide is that it is a set of primitive mechanisms
that could be used to build higher level reflection facilities. If
we had a strong use case we could
2008/7/18 Allen Wirfs-Brock [EMAIL PROTECTED]:
We ultimately concluded that the best way to think about what we are
currently provide is that it is a set of primitive mechanisms that could be
used to build higher level reflection facilities. If we had a strong use case
we could reintroduce
On Fri, Jul 18, 2008 at 7:39 AM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
John,
Thanks for pulling together all the various versions of Object.extend.
Not all.
It's useful to have them in one place.
There are a couple of things you mentioned that I wanted to clarify.
Neither
On Fri, Jul 18, 2008 at 10:56 AM, John Resig [EMAIL PROTECTED] wrote:
Not true. YAHOO.lang.extend uses prototypal inheritance.
YAHOO.lang.extend is similar in name only - YAHOO.lang.augmentObject is the
one that's actually similar to the functionality used by other code bases.
You're prev
On Wed, Jul 16, 2008 at 5:50 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Jul 16, 2008, at 4:10 PM, Allen Wirfs-Brock wrote:
[snip]
1) It seems like Object.clone as you have described it is not suitable
for the mixin type use case where an object gets properties/methods
from two
You're prev response seems to have come from the discussion of
Object.create.
No? We've been discussing the viability of a new Object.extend() method to be
introduced in ES3.1. Mozilla has offered a proposal and is looking to implement
it in SpiderMonkey. I provided examples of
-Original Message-
From: [EMAIL PROTECTED] [mailto:es4-discuss-
[EMAIL PROTECTED] On Behalf Of John Resig
No? We've been discussing the viability of a new Object.extend() method
to be introduced in ES3.1. Mozilla has offered a proposal and is
looking to implement it in SpiderMonkey.
-Original Message-
From: [EMAIL PROTECTED] [mailto:es4-discuss-
[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Friday, July 18, 2008 12:28 PM
...
You're prev response seems to have come from the discussion of
Object.create. Object.create, with only one argument, is the same as
-Original Message-
From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 10:31 AM
...
Neither Object.create nor Object.clone was not intended to be a
directly replacement for Object.extend.
Make that:
Neither Object.create or Object.clone were intended
On Fri, Jul 18, 2008 at 12:40 PM, John Resig [EMAIL PROTECTED] wrote:
You're prev response seems to have come from the discussion of
Object.create.
No? We've been discussing the viability of a new Object.extend() method to be
introduced in ES3.1.
The title of the thread is object static
On Fri, Jul 18, 2008 at 2:02 PM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:es4-discuss-
[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Friday, July 18, 2008 12:28 PM
...
You're prev response seems to have come from the
, July 16, 2008 10:15 PM
To: Brendan Eich; Allen Wirfs-Brock
Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document
Arguably, some of the need for direct prototype access is
alleviated by providing the clone method. However, there are still
On Jul 16, 2008, at 10:14 PM, Kris Zyp wrote:
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
Subject: RE: ES3.1 Object static methods rationale document
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
2008/7/16 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
I've got one objection to Object.getPrototypeOf: It allows inspection
and modification of prototype chains established like
, 2008 7:10:21 PM GMT -05:00 US/Canada Eastern
Subject: RE: ES3.1 Object static methods rationale document
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
On Thu, Jul 17, 2008 at 8:37 AM, John Resig [EMAIL PROTECTED] wrote:
I wanted to bring up some further evidence for the widespread use of an
extend() method. Here are the top 5 JavaScript libraries and their associated
versions of Object.extend():
There are a couple points that are very
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
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
:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 12:37 AM
To: Allen Wirfs-Brock
Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@mozilla.org es4-discuss
Subject: Re: ES3.1 Object static methods rationale document
On Jul 16, 2008, at 12:09 AM, Brendan Eich wrote:
On Jul 15, 2008, at 11:50 PM, Brendan
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?
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
agreement on
one of these that we have been discussing.
Allen
-Original Message-
From: Brendan Eich [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 11:52 AM
To: Allen Wirfs-Brock
Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@mozilla.org es4-discuss
Subject: Re: ES3.1 Object static
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
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
@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document
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
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
, 2008 2:27 PM
To: David Flanagan
Cc: es4-discuss@mozilla.org es4-discuss
Subject: Re: ES3.1 Object static methods rationale document
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
.
-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 could just give
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
Flanagan
Cc: es4-discuss@mozilla.org es4-discuss
Subject: Re: ES3.1 Object static methods rationale document
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
: Robert Sayre; Mark S. Miller; [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document
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
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
47 matches
Mail list logo
