f 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,
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 t
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
> -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
> -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
> -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 SpiderM
> 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 Object.exte
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
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'
> 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.
--John
___
Es4-discuss mailing list
Es4-d
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 O
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 reintro
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 coul
Wirfs-Brock
Cc: 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,getOwnP
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
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 Schoult
om: "Allen Wirfs-Brock" <[EMAIL PROTECTED]>
To: "Robert Sayre" <[EMAIL PROTECTED]>, "Mark S. Miller" <[EMAIL PROTECTED]>
Cc: "es3 x-discuss" <[EMAIL PROTECTED]>, es4-discuss@mozilla.org
Sent: Wednesday, July 16, 2008 7:10:21 PM GMT -05:00 US
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 a
> replacement for an extend method.
>
> I have a pure-JavaScript version of Object.extend() that I'm working on - and
> I'm building a test suite for it, as well (to make sure all edge cases are
> properly defined and handled):
> http://ejohn.org/files/object-extend.js
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
CTED]>
To: "Robert Sayre" <[EMAIL PROTECTED]>, "Mark S. Miller" <[EMAIL PROTECTED]>
Cc: "es3 x-discuss" <[EMAIL PROTECTED]>, es4-discuss@mozilla.org
Sent: Wednesday, July 16, 2008 7:10:21 PM GMT -05:00 US/Canada Eastern
Subject: RE: ES3.1 Object static
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 used
ty of the created object
would be an object that looks like a property descriptor.
From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 9:17 PM
To: Allen Wirfs-Brock
Cc: es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document
2008/7/15 Allen
TED]
Sent: Wednesday, 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 m
>> 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
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
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?
__
Allen Wirfs-Brock
Cc: 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 insta
ginal 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 methods rationale
Brendan Eich wrote:
> 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 alternati
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
old API but perhaps reimplementing them using the new
primitives.
-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 sta
half 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 methods rationale document
>
> On Jul 16, 2008, at 1:41 PM, David Flanagan wrote:
>
>> Brendan, I think you were corre
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 Obj
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
rendan Eich; [EMAIL PROTECTED]; es4-discuss@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 usef
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
> "descr
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 the discussion to exclude it.
- Rob
2008/7/16 Mark S. Miller <[EMAIL PROTECT
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 "t
On Wed, Jul 16, 2008 at 1:41 PM, David Flanagan <[EMAIL PROTECTED]> wrote:
> Brendan Eich wrote:
>>
> Frankly, though, I imagine that defining properties will be more common
> than reflecting on them, and I don't see anything wrong with a long name
> that explicitly describes the function: getProp
Brendan Eich wrote:
>
> Cool. I'm standing pat on describeProperty.
>
> /be
>
[I've removed es3.x-discuss, since I'm not a member]
The verb describe makes this sound like a setter method rather than a
getter method. That is, describeProperty sounds like a short name for
setPropertyDescriptor
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
-Original Message-
From: Brendan Eich [mailto:[EMAIL PROTECTED]
But you raise a good
point: defineProperty creates an own property. Is there really a need
for getProperty as drafted? If not, I'd favor making describeProperty
return null if the named property is not "own", but in a prototyp
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 Thesauru
TECTED] x-discuss; es4-discuss@mozilla.org es4-discuss
Subject: Re: ES3.1 Object static methods rationale document
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
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".
>
> Wha
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"?
> Re
ty]].
Also step 4 has a "]]" that should be there.
-Original Message-
From: Brendan Eich [mailto:[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 m
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 inspectPropert
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 t
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 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 thing we did
not include, it would be quite a long
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
sday, July 16, 2008 5:39 AM
To: Brendan Eich
Cc: Allen Wirfs-Brock; [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document
Brendan Eich wrote:
> * No rationale responding to the thread containing this message:
>
> https://mail.mozilla.org/pipermai
Brendan Eich wrote:
> * No rationale responding to the thread containing this message:
>
> https://mail.mozilla.org/pipermail/es4-discuss/2007-September/001114.html
>
> that questions the wisdom of getPrototypeOf. The other rationales are
> helpful, the lack of one responding to this public thre
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. getPropertyDescript
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
> long, but not fatally so. Worth renami
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%
3A
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%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:rationale
59 matches
Mail list logo
