Object.is steps are very thing
Sorry for the typo in the title :)
Le 16/03/2013 19:18, Tom Schuster a écrit :
Hey!
Looking at the the steps for Object.is the first sentence just says:
"When the is function is called with arguments value1 and value2 the following steps are taken:" I don't remember other functions being defined like that. It should at least say something along the lines of "When called with less than 2 parameters return false."
I'd throw a TypeError. Calling Object.is with strictly more or less than 2 parameters is most likely an error, akin to === with which something different than strictly 2 operands resultsis a SyntaxError.
On Mar 16, 2013, at 11:18 AM, Tom Schuster wrote:
Hey!
Looking at the the steps for Object.is the first sentence just says:
"When the is function is called with arguments value1 and value2 the following steps are taken:" I don't remember other functions being defined like that. It should at least say something along the lines of "When called with less than 2 parameters return false."
Most built-in functions are described in this manner. In fact, the preamble text for for Object.is was copied/pasted/edited from a previously existing Object constructor methods.
In general, we prefer to exclusively describe the semantics of built-ins using the algorithmic steps and to avoid redundancy between the preambles and the algorithms. When I notice it, generally remove such redundancy that is left over from earlier editions.
Paragraph 4 of the introduction to chapter 15 says that any parameters for which arguments are not provided have the value undefined. So we don't need to say anything about what happens if fewer or more than 2 arguments are passed.
On Mar 16, 2013, at 3:40 PM, David Bruant wrote:
Le 16/03/2013 19:18, Tom Schuster a écrit :
Hey!
Looking at the the steps for Object.is the first sentence just says:
"When the is function is called with arguments value1 and value2 the following steps are taken:" I don't remember other functions being defined like that. It should at least say something along the lines of "When called with less than 2 parameters return false." I'd throw a TypeError. Calling Object.is with strictly more or less than 2 parameters is most likely an error, akin to === with which something different than strictly 2 operands resultsis a SyntaxError.
ECMAScript has a well established convention of using undefined for any non-supplied argument values. It's preferable to consistently follow such conventions.
I would argue that the disclaimer makes this more confusing. I am aware of the behavior that not passed parameters are undefined. But It sounded like we would never execute step 1. when the parameter count doesn't match. And thus leaving the result of the call not defined.
Has using more powerful function/method signatures ever been a consideration for the spec? For example, type annotations could replace imperative coercions.
On Mar 16, 2013, at 4:42 PM, Tom Schuster wrote:
I would argue that the disclaimer makes this more confusing. I am aware of the behavior that not passed parameters are undefined. But It sounded like we would never execute step 1. when the parameter count doesn't match. And thus leaving the result of the call not defined.
I see...it certainly isn't intended for those preambles to be interpreted in that way. They really are just boiler plate for inducing the the italic parameter names.
If there is an actual overload based upon the number of passed arguments we are much more explict. See for example, 15.4.1.1 and 15.4.1.2.
Nobody had previously brought this particular point of confusion to may attention. It should like I shold change the standard boiler plate preamble to something slike:
The is function takes parameters /value1/ and /value2/ and performs the following steps when called:
On Mar 16, 2013, at 4:49 PM, Axel Rauschmayer wrote:
Has using more powerful function/method signatures ever been a consideration for the spec? For example, type annotations could replace imperative coercions.
I am applying ES6 style default value and rest parameter conventions to the chapter 15 signatures.
Given that ES coercions generally may have observable side-effects, I think the imperative coercions is exactly what we need as it place strictly orders the occurrence of each coercion (needed for interoperability) and allows coercions to be deferred until the point in the algorithm where the result is actually needed. WebIDL takes the signature driven approach and it leads to early and unnecessary coercions.
I also think that automatically coercions are get in the way of the sort of ad hoc overload determination that is used within some JavaScript functions.
On Mar 16, 2013, at 5:02 PM, Tom Schuster wrote:
Also note that with the current definition Object.is() should return true. I am not really a big fan of that ;)
All standard function have a well specified, but perhaps odd, behavior when no arguments are passed to them. It's just how JavaScript works. Better to have a simple rule to learn than dozens of exceptions.
Allen Wirfs-Brock wrote:
On Mar 16, 2013, at 5:02 PM, Tom Schuster wrote:
Also note that with the current definition Object.is() should return true. I am not really a big fan of that ;)
All standard function have a well specified, but perhaps odd, behavior when no arguments are passed to them. It's just how JavaScript works. Better to have a simple rule to learn than dozens of exceptions.
Object.is() // true
It has a nice existentialist ring to it!
On Sat, Mar 16, 2013 at 7:56 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
On Mar 16, 2013, at 4:42 PM, Tom Schuster wrote:
I would argue that the disclaimer makes this more confusing. I am aware of the behavior that not passed parameters are undefined. But It sounded like we would never execute step 1. when the parameter count doesn't match. And thus leaving the result of the call not defined.
I see...it certainly isn't intended for those preambles to be interpreted in that way. They really are just boiler plate for inducing the the italic parameter names.
If there is an actual overload based upon the number of passed arguments we are much more explict. See for example, 15.4.1.1 and 15.4.1.2.
Nobody had previously brought this particular point of confusion to may attention. It should like I shold change the standard boiler plate preamble to something slike:
The is function takes parameters /value1/ and /value2/ and performs the following steps when called:
I disagree that the language is at all confusing. The existing preamble is consistent and makes sense in the context of describing a public API that delegates to an abstract operation.
If the reader needs any further information about the semantics of Object.is, the algorithmic steps for SameValue are thorough.
I like to disagree. I was quite familiar with the ES spec about a year ago and this still confused me. Only because this is pre-existing doesn't make the language very clear.
Tom
Tom Schuster wrote:
I like to disagree. I was quite familiar with the ES spec about a year ago and this still confused me. Only because this is pre-existing doesn't make the language very clear.
I agree it's a bit awkward learning to read every Clause 15 method spec in terms of the Clause 15 intro's subtle language about missing arguments. Kind of a pain, really. But in the interest of a minimal spec, to avoid redundancy that can then mutate and diverge, making spec bugs, we generally try to hoist such common "code", if you will.
Do you think a specific change should be made for Object.is, or for all method specs in 15?
Hey!
Looking at the the steps for Object.is the first sentence just says:
I don't remember other functions being defined like that. It should at least say something along the lines of "When called with less than 2 parameters return false."