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
The fixture question is a good one, but takes some thought to answer well so
I'm not going to tackle it until tomorrow.
The other questions are easy:
1) as currently specified, unrecognized properties of a property descriptor are
ignored.
2) no, in your example, the value of the o1 property of
Object.create does not support changing the [[Prototype]] of an already
instantiated object, if that was the question. It creates a new object with a
caller specified [[Prototype]] value. Dynamic modification of an already
instantiated object's [[Prototype]] is not something that I'm ready to
>> 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?
__
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 defineProp
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, Alle
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
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
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
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 ha
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 i
Latest news in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=430740#c42
Igor wrote:
"So MSIE simply treats BOM as a whitespace for the purpose of
parsing. Which
suggests to do this in SM to fix the bug: treat BOM as one of Unicode
whitespace characters in the scanner avoiding any chara
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 m
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 coul
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 w
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
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, Writ
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
(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 al
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
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 th
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
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
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
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
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 fla
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
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.
It's true that __proto__ or getPrototypeOf breaks an object's encapsulation
barrier and reveals implementation details that perhaps w
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
Mark wrote:
> Adding decimal to Rhino would presumably build on the BigDecimal
> class already present in Java. Is Java's BigDecimal class
> sufficiently conformant to the relevant IEEE spec to support a
> conformant implementation of the decimal proposed for EcmaScript?
It follows the same a
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
43 matches
Mail list logo
