Kona [[Getter]] and [[Setter]] descriptions
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?
[[Getter]] A zero-argument method called each time the property is read.
[[Setter]] A one-argument method called each time the property is assigned.
I agree with this argument. These descriptions are simple and sufficiently general.
-----Original Message----- From: es-discuss-bounces at mozilla.org [mailto:es-discuss- bounces at mozilla.org] On Behalf Of Peter Michaux Sent: Saturday, November 15, 2008 10:47 PM To: es-discuss at mozilla.org Subject: Kona [[Getter]] and [[Setter]] descriptions
From section 8.6.1 ... Would the following be sufficient?
[[Getter]] A zero-argument method called each time the property is read.
[[Setter]] A one-argument method called each time the property is assigned.
I generally agree but propose a slight variant of Peter's proposed definitions:
[[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 assigned. The effect of a property's [[Setter]] function may but it not required to have an effect on the value returned by subsequent calls to the property's [[Getter]] function.
On Sun, Nov 16, 2008 at 10:11 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com>
[[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 assigned. The effect of a property's [[Setter]] function may but it not required to have an effect on the value returned by subsequent calls to the property's [[Getter]] function.
These descriptions are going back towards the idea of "state" and a connection between getting and setting. I don't think that is necessary even though that is the motivation for their existence. Getting and setting are two totally disjoint operations unless a particular object is implemented so they are connected.
Peter
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, I think the descriptive text in these tables need to be considered as informative rather than normative. The normative definitions of the getters and setters is provided by the algorithms of the specifications. Overall, I don't this document (and its predecessors) does a very good job at clearly distinguishing the informative from the normative.
On Sun, Nov 16, 2008 at 10:57 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> 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 if [[Getter]] said "called to produce" rather than "called to return"?
If the connection between [[Getter]] and [[Setter]] is clearly indicated to be "not necessary" then I think that is ok (but unnecessary.) The names "Getter" and "Setter" make the connection but perhaps a explicit note that there is no necessary connection is a good idea.
Yes "produce" seems much better.
How about...
[[Getter]] A zero-argument function called to produce the property value each time the property read.
[[Setter]] A one-argument function called with the assigned value each time the property is assigned. The effect of a property's [[Setter]] function may, but is not required to, affect the value produced by subsequent calls to the property's [[Getter]] function.
In general, I think the descriptive text in these tables need to be considered as informative rather than normative. The normative definitions of the getters and setters is provided by the algorithms of the specifications. Overall, I don't this document (and its predecessors) does a very good job at clearly distinguishing the informative from the normative.
I thought these descriptions might be non-normative but it is not stated. I agree that the descriptions should be marked as non-normative.
Peter
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 zero-argument method called to produce the property value each time the property is read.
[[Setter]] A one-argument method called with the assigned value each time the property is assigned. The effect of a property's [[Setter]] method may, but is not required to, affect the value produced by subsequent calls to the property's [[Getter]] method.
On Sun, Nov 16, 2008 at 11:28 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> 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 final form would be:
[[Getter]] A zero-argument method called to produce the property value each time the property is read.
[[Setter]] A one-argument method called with the assigned value each time the property is assigned. The effect of a property's [[Setter]] method may, but is not required to, affect the value produced by subsequent calls to the property's [[Getter]] method.
Looks good to me. Now what happens. Do you add this to a ticket somewhere?
Peter
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
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 start using the
"ES4" Trac server
Please do -- it should work, and it's not specific to ES4. I'll look
into options for segregating bugs so the old ones don't get in the
way, except to continue holding numbers. Bug numbers are forever.
Peter Michaux wrote:
On Sun, Nov 16, 2008 at 10:11 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com>
[[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 assigned. The effect of a property's [[Setter]] function may but it not required to have an effect on the value returned by subsequent calls to the property's [[Getter]] function.
These descriptions are going back towards the idea of "state" and a connection between getting and setting. I don't think that is necessary even though that is the motivation for their existence. Getting and setting are two totally disjoint operations unless a particular object is implemented so they are connected.
Yes. How about this:
[[Getter]] A zero-argument function that is called each time the property is read (via a [[Get]] operation), to return the result of the read.
[[Setter]] A one-argument function that is called with the written value each time the property is written (via a [[ThrowablePut]] operation).
The references to [[Get]] and [[ThrowablePut]] are needed because it is possible for host objects to override any of the internal methods in such a way that [[Getter]] and [[Setter]] are not used, even when there is a property read (call to GetValue) or write (call to PutValue).
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 final form would be:
[[Getter]] A zero-argument method called to produce the property value each time the property is read.
[[Setter]] A one-argument method called with the assigned value each time the property is assigned. The effect of a property's [[Setter]] method may, but is not required to, affect the value produced by subsequent calls to the property's [[Getter]] method.
It is unclear what "read" and "assigned" mean here. If they mean uses of GetValue and PutValue, the descriptions are not strictly correct.
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 server
Just as non-TC39-members can't currently edit the wiki, they can't submit Trac issues, either.
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 how [[Getter]] and [[Setter]] are used.
Also, we have plenty of time over the next couple months to fine tune this sort of language. In preparations for next week meeting it is probably most important to put time into identifying where there are real unresolved technical decisions that need to be finalized. Tweaking the wording the reflect the intent of those decisions can follow after the meeting.
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 ThrowablePut (the Put is not the object
thrown, an exception is).
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. Hopefully, we can just adopt and start using the "ES4" Trac serverJust as non-TC39-members can't currently edit the wiki, they can't submit Trac issues, either.
That was not true for the longest time. Then we got spammed.
We've added access to those who request it and have good rep. We're
not throwing things open to the world. I still haven't heard back from
you whether you want access, BTW.
On Sun, Nov 16, 2008 at 11:36 PM, Brendan Eich <brendan at mozilla.com> 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 ThrowingPut would be better. Or FalliblePut, or to be long-winded, PutCapableOfThrowing but not ThrowablePut (the Put is not the object thrown, an exception is).
Any of these are better. ThrowingPut indicates what happens when failure occurs and I think that is good if throwing is always what happens when failure occurs. FailablePut doesn't make such indication.
Peter
On Nov 16, 2008, at 11:49 PM, Peter Michaux wrote:
Total nit, but ThrowingPut would be better. Or FalliblePut, or to be long-winded, PutCapableOfThrowing
but not ThrowablePut (the Put is not the object thrown, an exception is).Any of these are better. ThrowingPut indicates what happens when failure occurs and I think that is good if throwing is always what happens when failure occurs. FailablePut doesn't make such indication.
Failure means an exception in ES3. I like FalliblePut better than
ThrowingPut; either is a fix to ThrowablePut.