Re: Argument matching
[+es3.x-discuss] On Fri, May 9, 2008 at 10:43 AM, Lars Hansen [EMAIL PROTECTED] wrote: In strict code (use strict) the number of passed arguments must match the number of expected arguments. This has been agreed upon. Hi Lars, much as it pains me to raise this again, it has *not* been agreed upon. In order for ES3.1 strict mode to be a fail-stop subset of ES4 strict mode, I don't see how we could possibly agree on this. Please include es3.x-discuss on further discussion of this topic. ES3.1 must define a language that depends only on features that will parse successfully on 3/4 of the current major browsers. Therefore, it cannot adopt ES4's notations for either optional or rest arguments. Instead, I have proposed that in ES3.1 strict mode, and *therefore* in ES4 strict mode as well: * If a function is invoked with fewer arguments than its declared parameters, the remaining parameters are bound to undefined. If an ES4 strict function wishes to reject calls with too few arguments, then it should declare undefined-rejecting types on these remaining parameters. * If a function is invoked with more arguments than its declared parameters, and if the function either mentions the magic name 'arguments' freely in its body or (ES4 only) declares rest parameters, then it is considered an unbounded arity function. Otherwise it is considered a bounded arity function. * If a strict bounded arity function is called with too many arguments, the call is rejected with a throw. I would expect that if too few arguments are passed to a function with a typed interface then you get a type error unless the missing parameter has a type that includes undefined (ie no conversion takes place). This should be the case for a strict function as well. Signalling an error because the function has a typed interface is a variant, I guess, but it seems like an orthogonal concern. Since ES3.1 has no typed interface, I will stay out of debates about the semantics of typed interfaces. I would expect excess arguments to typed functions to be ignored silently, as they can be picked up by 'arguments' inside the function. In loose mode, yes. It strict mode, only of 'arguments' is mentioned freely in the body of the function, or (ES4 only) if the function declares rest parameters. -- Cheers, --MarkM ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Argument matching
On Fri, May 9, 2008 at 11:21 AM, Lars Hansen [EMAIL PROTECTED] wrote: There are optional and rest arguments in ES4. Regarding error reporting, strict mode is what gives you sane error checking (generally at run-time). Standard mode is for all you cowboys out there. As a separate matter, that has been raised by others as well: Since both modes are to be specified by upcoming standards documents, can we adopt some term other than standard for the mode we'd like to discourage? I propose loose. -- Cheers, --MarkM ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: getter and setter inheritance
When an object A is defined that inherits from it's prototype object B that
has a getter and setter defined for foo, and object A wants to inherit the
behavior of B except for a slight modification to the getter behavior, it
could be advantageous if the setter could still be inherited without having
to redefine it on object A. If the developer wants to make property foo
read-only, this can still easily be done by creating a setter that throws an
exception (or does nothing).
That being said, I would still favor the approach of treating
getters/setters as a full slot, where inheritance doesn't go past
half-definitions because that is behavior that is currently used on the web
today.
Also, the idea of making setters without getters illegal is interesting.
However, while they may be rare, I think setters without getters has use
cases. This seems like unnecessary arbitrary restriction to dissallow
setters without getters. Furthermore, this is not the behavior of current
browsers, there is no precedent in JavaScript implementations for preventing
this combination. Is there other reasons for this restriction that I am not
aware of?
Thanks,
Kris
- Original Message -
From: Mark S. Miller [EMAIL PROTECTED]
To: Kris Zyp [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; es4-discuss Discuss
es4-discuss@mozilla.org
Sent: Sunday, May 11, 2008 10:23 AM
Subject: Re: getter and setter inheritance
2008/5/9 Kris Zyp [EMAIL PROTECTED]:
A question of how inheritance/delegation should work with getters and
setters was raised in a recent discussion.
Hi Kris,
The way I've been thinking of getters and setters is as if there are
two kinds of properties:
* A data property is defined by its current value, and whether the
value is writable. If the value is not writable, the property is
considered read-only.
* A procedural property is defined by a getter function and an
optional setter function. If there is no setter function, the property
is considered read-only.
For both kinds of properties, a property is further defined by its
property name, whether the property is enumerable, and whether the
property's definition is redefinable. (Where redefinable implies
deletable.) This would be reflected (so to speak) concretely in the
results of Object.getProperties and Object.getProperty, and in the
argument of Object.defineProperties.
Object.getProperty(x, 'foo') = {value: 3, writable: false,
enumerable: false, redefinable: false}
Object.getProperty(x, 'bar') = {getter: function(){return 3;},
enumerable: false, redefinable: false}
in which case x.foo and x.bar are behaviorally identical for
non-reflective clients.
If there is an object A whose
prototype is object B, and object A defines a getter for property foo,
and
object B defines a setter for property foo, and we write a value to
A.foo,
should the setter defined on object B be called?
I think it should be illegal to define a setter without defining a
getter. A procedural property should either have a getter or have a
getter and a setter.
Assuming B defines a getter and a setter for foo, and A defines a
getter for foo, the answer should be no. A's own foo is a read-only
procedural property that fully masks B's foo.
If A didn't define any
property on A, the setter would be inherited from B and would be called
when
A.foo was modified.
Yes.
However, with the getter defined on A, should the
inheritance stop at A, because there is a slot defined, or should it
continue along the prototype chain because there was no setter defined
for
that property (nor plain value)?
Stop at A. s/slot/property
The question also applies when the getter
and setter are reversed. When a property is accessed and there is a
setter
defined, but no getter,
That case should be rejected as illegal.
should we continue to down the prototype chain to
find a getter or a plain value, or stop and return undefined? AFAICT, ES4
doesn't explicitly define which is the correct behavior. Firefox follows
the
former behavior:
B={set foo(v){foo = v},
get bar(){return bar value}}
B.foo should be rejected as illegal.
A={get foo(){return foo value},
set bar(v){bar = v},
__proto__:B}
A.bar should be rejected as illegal.
--
Cheers,
--MarkM
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: getter and setter inheritance
On Sun, May 11, 2008 at 4:40 PM, Kris Zyp [EMAIL PROTECTED] wrote:
[...] That being said, I would still favor the approach of treating
getters/setters as a full slot, where inheritance doesn't go past
half-definitions because that is behavior that is currently used on the web
today.
Great!
Also, the idea of making setters without getters illegal is interesting.
However, while they may be rare, I think setters without getters has use
cases. This seems like unnecessary arbitrary restriction to dissallow
setters without getters. Furthermore, this is not the behavior of current
browsers, there is no precedent in JavaScript implementations for preventing
this combination. Is there other reasons for this restriction that I am not
aware of?
Not really. I can live with write-only procedural properties. I don't
think it changes any of the other points.
When reading a write-only property, i.e., a procedural property with a
setter and no getter, one reads undefined, even in strict mode. Right?
So an absent getter is always equivalent to a getter of
function(){return undefined;}?
--
Cheers,
--MarkM
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
