The name "JSON.stringify" seems a little too "Web 2.0" cool to me. Is
there any reason a more usual and serious sounding option like
"serialize" was not used? Both are nine characters. I think there is a
marketing issue here elevating JavaScript from a "toy language".
Although that concept has been
On Sun, Nov 16, 2008 at 11:36 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Nov 16, 2008, at 7:32 PM, David-Sarah Hopwood wrote:
>
>> The references to [[Get]] and [[ThrowablePut]] are needed because it is
>
> Anyone else find ThrowablePut misnamed?
I thought it was confusing.
> Total nit, but
On Nov 16, 2008, at 8:48 PM, David-Sarah Hopwood wrote:
Allen Wirfs-Brock wrote:
I'll make sure Pratap edits it into the working draft.
I intend to propose at the Kona meeting that we have reached a
point where
we need to move to a strict ticket driven process for the ES3.1
endgame.
Hopef
On Nov 16, 2008, at 7:32 PM, David-Sarah Hopwood wrote:
The references to [[Get]] and [[ThrowablePut]] are needed because it
is
Anyone else find ThrowablePut misnamed? Total nit, but ThrowingPut
would be better. Or FalliblePut, or to be long-winded,
PutCapableOfThrowing but not ThrowableP
While I think it is fine to be tuning the language of these definition, the key
point, as I mentioned in an earlier message, is that these definitions are not
really normative with regard to such behavior. There are other normative
portions of the specification that define precisely when and ho
Allen Wirfs-Brock wrote:
> I'll make sure Pratap edits it into the working draft.
>
> I intend to propose at the Kona meeting that we have reached a point where
> we need to move to a strict ticket driven process for the ES3.1 endgame.
> Hopefully, we can just adopt and start using the "ES4" Trac
Allen Wirfs-Brock wrote:
> OK, I like those definitions. Even though I just changed it I would now go
> back to calling them methods rather than functions (because this is bound
> when the functions are invoked). Also we lost the "is" before "read" in the
> [[Getter]] definition. So, the fina
Ecma would prefer that we follow the ISO Directives, Part 2. In there you
will find that "shall" and "may" are the words to use
John
**Get the Moviefone Toolbar. Showtimes, theaters, movie news &
more!(http://pr.atwola.com/promoclk/10075x1212774565x1200812037/aol?redir=htt
p:/
Peter Michaux wrote:
> On Sun, Nov 16, 2008 at 6:42 PM, David-Sarah Hopwood
> <[EMAIL PROTECTED]> wrote:
>> Peter Michaux wrote:
>>> On Sat, Nov 15, 2008 at 11:18 PM, Peter Michaux <[EMAIL PROTECTED]> wrote:
>>>
Also is it "should" or "must"? RFC documents are usually very strict
about de
Peter Michaux wrote:
> On Sun, Nov 16, 2008 at 10:11 AM, Allen Wirfs-Brock
> <[EMAIL PROTECTED]>
>
>> [[Getter]] A zero-argument function that is called to return the property
>> value each time the property read.
>>
>> [[Setter]] A one-argument function that is called with the assigned value
On Nov 16, 2008, at 6:42 PM, David-Sarah Hopwood wrote:
Peter Michaux wrote:
On Sat, Nov 15, 2008 at 11:18 PM, Peter Michaux <[EMAIL PROTECTED]
> wrote:
Also is it "should" or "must"? RFC documents are usually very strict
about defining "should" etc and I don't see a definition of "should"
On Sun, Nov 16, 2008 at 6:42 PM, David-Sarah Hopwood
<[EMAIL PROTECTED]> wrote:
> Peter Michaux wrote:
>> On Sat, Nov 15, 2008 at 11:18 PM, Peter Michaux <[EMAIL PROTECTED]> wrote:
>>
>>> Also is it "should" or "must"? RFC documents are usually very strict
>>> about defining "should" etc and I don'
Peter Michaux wrote:
> On Sat, Nov 15, 2008 at 11:18 PM, Peter Michaux <[EMAIL PROTECTED]> wrote:
>
>> Also is it "should" or "must"? RFC documents are usually very strict
>> about defining "should" etc and I don't see a definition of "should"
>> before page 41 of the pdf where this use occurs.
>
On Sun, Nov 16, 2008 at 1:31 PM, Allen Wirfs-Brock
<[EMAIL PROTECTED]> wrote:
> In principle I agree. However, ECMA has its own usage guidelines that we
> will need to make sure we conform with.
It isn't so important who is defining these terms but the source of
the definitions should be present
In principle I agree. However, ECMA has its own usage guidelines that we will
need to make sure we conform with.
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:es-discuss-
>[EMAIL PROTECTED] On Behalf Of Peter Michaux
>Sent: Sunday, November 16, 2008 1:27 PM
>To: es-discuss@mozilla
On Sat, Nov 15, 2008 at 11:18 PM, Peter Michaux <[EMAIL PROTECTED]> wrote:
> Also is it "should" or "must"? RFC documents are usually very strict
> about defining "should" etc and I don't see a definition of "should"
> before page 41 of the pdf where this use occurs.
http://www.ietf.org/rfc/rfc21
On Nov 16, 2008, at 11:57 AM, Allen Wirfs-Brock wrote:
I'll make sure Pratap edits it into the working draft.
I intend to propose at the Kona meeting that we have reached a point
where we need to move to a strict ticket driven process for the
ES3.1 endgame. Hopefully, we can just adopt and
I'll make sure Pratap edits it into the working draft.
I intend to propose at the Kona meeting that we have reached a point where we
need to move to a strict ticket driven process for the ES3.1 endgame.
Hopefully, we can just adopt and start using the "ES4" Trac server
>-Original Message---
On Sun, Nov 16, 2008 at 11:28 AM, Allen Wirfs-Brock
<[EMAIL PROTECTED]> wrote:
> OK, I like those definitions. Even though I just changed it I would now go
> back to calling them methods rather than functions (because this is bound
> when the functions are invoked). Also we lost the "is" before
OK, I like those definitions. Even though I just changed it I would now go
back to calling them methods rather than functions (because this is bound when
the functions are invoked). Also we lost the "is" before "read" in the
[[Getter]] definition. So, the final form would be:
[[Getter]] A z
On Sun, Nov 16, 2008 at 10:57 AM, Allen Wirfs-Brock
<[EMAIL PROTECTED]> wrote:
> I think the connection is commonly expected so that possibility should be
> acknowledge but also emphasized as not being required. Would you concern
> about implying some implicit maintenance of state be alleviated
I think the connection is commonly expected so that possibility should be
acknowledge but also emphasized as not being required. Would you concern about
implying some implicit maintenance of state be alleviated if [[Getter]] said
"called to produce" rather than "called to return"?
In general,
On Sun, Nov 16, 2008 at 10:11 AM, Allen Wirfs-Brock
<[EMAIL PROTECTED]>
> [[Getter]] A zero-argument function that is called to return the property
> value each time the property read.
>
> [[Setter]] A one-argument function that is called with the assigned value
> each time the property is a
In addition to David-Sarah's points we hoped that repurposing the DontDelete
attribute as [[Configurable]] would ease implementation level transition from
ES3 to ES3.1. Assuming a implementation already has single bit encodings to
represent DontDelete, DontEnum, and ReadOnly is may be less disr
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:es-discuss-
>[EMAIL PROTECTED] On Behalf Of Peter Michaux
>Sent: Saturday, November 15, 2008 10:47 PM
>To: es-discuss@mozilla.org
>Subject: Kona [[Getter]] and [[Setter]] descriptions
>
>From section 8.6.1
...
>Would the following be suff
Peter Michaux wrote:
>>From 8.6.1, Table 2
>
> [[Configurable]]
> If true, attempts to delete the property, change the property to a
> data property, or change its attributes will succeed.
>
> This looks like at least three orthogonal properties to me.
>
> [[Deletable]]
> If true, attempts to de
Peter Michaux wrote:
> Is there any need to discuss state at all when describing getters and
> setters? The motivation for getters and setters may have been to
> affect state, that isn't their only possible use. They are more
> generic than that.
>
> Would the following be sufficient?
>
> [[Gette
27 matches
Mail list logo
