ARGUMENTS.SHOULD.BE.ARRAY bug-fix

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

ARGUMENTS.SHOULD.BE.ARRAY bug-fix

Vassily Gavrilyak
Spec states that arguments should be an object that delegates to Array.prototype
So now actually argument will finally be array and used as such.

The question is - will the caller side of function arguments be fixed
the same way.
So the following code will work

function foo(){
  alert(arguments.join());
}

foo.apply(this, [1,,2]);
foo.call (this,  1,,2);
this.fool(1,,2);

All 3 statements means the same and looks symmetrically, but second
and third give
compiler errors. Is that addressed too, so we will actually have
arguments === Array?


Regards,
Vassily Gavrilyak
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix

liorean
On 18/03/07, Vassily Gavrilyak <[hidden email]> wrote:

> The question is - will the caller side of function arguments be fixed
> the same way.
> So the following code will work
>
> function foo(){
>   alert(arguments.join());
> }
>
> foo.apply(this, [1,,2]);
> foo.call (this,  1,,2);
> this.fool(1,,2);
>
> All 3 statements means the same and looks symmetrically, but second
> and third give
> compiler errors. Is that addressed too, so we will actually have
> arguments === Array?

Isn't the first more analogous to the following?

    foo.call(this,1,undefined,2);
    this.foo(1,undefined,2);

fn.apply destructures the array, with undefined taking place of
elisions, into the arguments to send. The arguments array of the
function activation is constructed from those sent arguments, not from
the array sent to apply.

On the other hand I don't see why elisions in function calls would
really be a problem...
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix

Vassily Gavrilyak
On 3/18/07, liorean <[hidden email]> wrote:

> On 18/03/07, Vassily Gavrilyak <[hidden email]> wrote:
> > The question is - will the caller side of function arguments be fixed
> > the same way.
> > So the following code will work
> >
> > function foo(){
> >   alert(arguments.join());
> > }
> >
> > foo.apply(this, [1,,2]);
> > foo.call (this,  1,,2);
> > this.fool(1,,2);
> >
> > All 3 statements means the same and looks symmetrically, but second
> > and third give
> > compiler errors. Is that addressed too, so we will actually have
> > arguments === Array?
>
> Isn't the first more analogous to the following?
>
>     foo.call(this,1,undefined,2);
>     this.foo(1,undefined,2);
>
> fn.apply destructures the array, with undefined taking place of
> elisions, into the arguments to send. The arguments array of the
> function activation is constructed from those sent arguments, not from
> the array sent to apply.
>
> On the other hand I don't see why elisions in function calls would
> really be a problem...
> --
> David "liorean" Andersson
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
Yes, of course it's the same. But still two different cases to
remember and deal with.
One behavior will be more consistent and less things to think about.

Regards
Vassily Gavrilyak
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix

Brendan Eich-2
The bug fix is clearly talking only about making arguments objects  
delegate to Array.prototype. It's not talking about new syntax to  
allow holes in actual parameter lists.

Note also how arguments' type may not be Array, but something  
delegating to Array.prototype. We need to finalize the spec, but  
already ES1-3 makes arguments a magic type that aliases arguments[0]  
to a in function f(a){...}. That's not something Array instances can  
do, and implementations take advantage of the fact that arguments  
appears to be an Object with magic native getter and setter behavior.  
Making arguments an Array would mean mixing in the magic, somehow. So  
when I wrote that bug fix originally, I intentionally described the  
fix as making the arguments object delegate to Array.prototype.

Holes in actual parameter lists are something I've never heard  
requested, and people already "remember" how to pass parameters in  
any C-like language. The issue is whether novices somehow might be  
confused by the ability to write [1, , 3] but not f(1, , 3). I doubt  
anyone would be much confused.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix

Vassily Gavrilyak
On 3/19/07, Brendan Eich <[hidden email]> wrote:

> The bug fix is clearly talking only about making arguments objects
> delegate to Array.prototype. It's not talking about new syntax to
> allow holes in actual parameter lists.
>
> Note also how arguments' type may not be Array, but something
> delegating to Array.prototype. We need to finalize the spec, but
> already ES1-3 makes arguments a magic type that aliases arguments[0]
> to a in function f(a){...}. That's not something Array instances can
> do, and implementations take advantage of the fact that arguments
> appears to be an Object with magic native getter and setter behavior.
> Making arguments an Array would mean mixing in the magic, somehow. So
> when I wrote that bug fix originally, I intentionally described the
> fix as making the arguments object delegate to Array.prototype.
The spec is clear, of course arguments can't be Array. They just
"feels" as Array.
>
> Holes in actual parameter lists are something I've never heard
> requested, and people already "remember" how to pass parameters in
> any C-like language. The issue is whether novices somehow might be
> confused by the ability to write [1, , 3] but not f(1, , 3). I doubt
> anyone would be much confused.
>
> /be
>
Well, I sometimes get confused. It's very rare cases, but still
happens to me. Don't remember any C-like language, but our cousin
VBScript
allows this. And those guys are sometimes confused too.
Like here. http://www.thescripts.com/forum/thread91618.html
That's 'very corner' case, but why not just fix it, if the fix will
not break anything?

Regards,
Vassily Gavrilyak
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix

Brendan Eich-2
On Mar 18, 2007, at 4:20 PM, Vassily Gavrilyak wrote:

> Well, I sometimes get confused. It's very rare cases, but still
> happens to me. Don't remember any C-like language, but our cousin
> VBScript
> allows this. And those guys are sometimes confused too.
> Like here. http://www.thescripts.com/forum/thread91618.html

Thanks, good information.

> That's 'very corner' case, but why not just fix it, if the fix will
> not break anything?

You're certainly right that this is a syntactic extension that won't  
break any existing code. Jeff Dyer should comment, since he's the  
grammar owner and has good taste ;-).

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix

Vassily Gavrilyak
On 3/19/07, Brendan Eich <[hidden email]> wrote:

> On Mar 18, 2007, at 4:20 PM, Vassily Gavrilyak wrote:
>
> > Well, I sometimes get confused. It's very rare cases, but still
> > happens to me. Don't remember any C-like language, but our cousin
> > VBScript
> > allows this. And those guys are sometimes confused too.
> > Like here. http://www.thescripts.com/forum/thread91618.html
>
> Thanks, good information.
>
> > That's 'very corner' case, but why not just fix it, if the fix will
> > not break anything?
>
> You're certainly right that this is a syntactic extension that won't
> break any existing code. Jeff Dyer should comment, since he's the
> grammar owner and has good taste ;-).
>
> /be
>
>
Thank you for considering this. While I can imagine why this
functionality was disabled in ES1-3 (to protect programmer from
misprints), in typed language typer could be responsible for handling
this, not grammar.
Well, let's wait for Jeff to comment.

>Note also how arguments' type may not be Array, but something
>delegating to Array.prototype. We need to finalize the spec, but
>already ES1-3 makes arguments a magic type that aliases >arguments[0]
>to a in function f(a){...}.
So we have a magic that makes position->name transition for arguments.
We also have destructuring magic. Shouldn't we go
further and add desctructuring magic to function call too? This way we
will get named arguments functionality, and that's something that
adds readability to code in some cases.
We can do emulate it right now (and I already do it) with hashes.
But having this magic in language will help to optimize such calls and
add readability.

Example

function Person(name, age){
    this.name = name;
    this.age     = age;
}

Now I can use it like
person = new Person("Joe", 20)

But much readable that I prefer to use is
person = new Person(name:"Joe", age:20);

I can simulate this with
person = new Person({name:"Joe", age:20})
and pay performance penalty for readability,
so my constructor will become something like this.

function Person(name, age){
    if(typeof(name) == "object"){
       var obj = name;
        this.name = obj.name;
        this.age = obj.age;
    }else{
       this.name = name;
       this.age     = age;
    }
}

Again, not a big issue, but a little speed-up for correct and readable
code will help.
Probably named parameters were already considered, in this case I'm
sorry for disturbing, just failed to find it in spec.


Regards,
Vassily Gavrilyak
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ARGUMENTS.SHOULD.BE.ARRAY bug-fix

Jeff Dyer


> -----Original Message-----
> From: [hidden email] [mailto:es4-discuss-
> [hidden email]] On Behalf Of Vassily Gavrilyak
> Sent: Monday, March 19, 2007 3:21 AM
> To: Brendan Eich
> Cc: [hidden email]; liorean
> Subject: Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix
>
> On 3/19/07, Brendan Eich <[hidden email]> wrote:
> > On Mar 18, 2007, at 4:20 PM, Vassily Gavrilyak wrote:
> >
> > > Well, I sometimes get confused. It's very rare cases, but still
> > > happens to me. Don't remember any C-like language, but our cousin
> > > VBScript
> > > allows this. And those guys are sometimes confused too.
> > > Like here. http://www.thescripts.com/forum/thread91618.html
> >
> > Thanks, good information.
> >
> > > That's 'very corner' case, but why not just fix it, if the fix
will

> > > not break anything?
> >
> > You're certainly right that this is a syntactic extension that won't
> > break any existing code. Jeff Dyer should comment, since he's the
> > grammar owner and has good taste ;-).
> >
> > /be
> >
> >
> Thank you for considering this. While I can imagine why this
> functionality was disabled in ES1-3 (to protect programmer from
> misprints), in typed language typer could be responsible for handling
> this, not grammar.
> Well, let's wait for Jeff to comment.

I'm not sure the type system will help much since 'undefined' will
silently convert to a value of most types. An argument list with holes
looks like mistake to me. Why not force the user to say what he means?

> >Note also how arguments' type may not be Array, but something
> >delegating to Array.prototype. We need to finalize the spec, but
> >already ES1-3 makes arguments a magic type that aliases >arguments[0]
> >to a in function f(a){...}.
> So we have a magic that makes position->name transition for arguments.
> We also have destructuring magic. Shouldn't we go
> further and add desctructuring magic to function call too? This way we
> will get named arguments functionality, and that's something that
> adds readability to code in some cases.
> We can do emulate it right now (and I already do it) with hashes.
> But having this magic in language will help to optimize such calls and
> add readability.
>
> Example
>
> function Person(name, age){
>     this.name = name;
>     this.age     = age;
> }
>
> Now I can use it like
> person = new Person("Joe", 20)
>
> But much readable that I prefer to use is
> person = new Person(name:"Joe", age:20);
>
> I can simulate this with
> person = new Person({name:"Joe", age:20})
> and pay performance penalty for readability,
> so my constructor will become something like this.
>
> function Person(name, age){
>     if(typeof(name) == "object"){
>        var obj = name;
>         this.name = obj.name;
>         this.age = obj.age;
>     }else{
>        this.name = name;
>        this.age     = age;
>     }
> }
>
> Again, not a big issue, but a little speed-up for correct and readable
> code will help.
> Probably named parameters were already considered, in this case I'm
> sorry for disturbing, just failed to find it in spec.

Named arguments has been discussed from time to time, but never had the
support to become a serious proposal. Both proposals here are future
proof and so I say let's hold off for now. We need to have something to
talk about when edition4 is done :)

Any else think differently?

Jd
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix

Brendan Eich-2
On Mar 19, 2007, at 11:10 AM, Jeff Dyer wrote:

>> Thank you for considering this. While I can imagine why this
>> functionality was disabled in ES1-3 (to protect programmer from
>> misprints), in typed language typer could be responsible for handling
>> this, not grammar.
>> Well, let's wait for Jeff to comment.
>
> I'm not sure the type system will help much since 'undefined' will
> silently convert to a value of most types. An argument list with holes
> looks like mistake to me. Why not force the user to say what he means?

Agreed. The type checker is an optional strict mode, anyway, so it  
can't help catch mistakes even if hole is not compatible with  
undefined or other typed values.

Note also that holes in arrays mean the property need not be  
allocated, which can save memory and survive hole-preserving  
operations. Not so with actual parameters or the arguments object, at  
least not in any implementation I know of. An arguments object is not  
an Array.

>> Probably named parameters were already considered, in this case I'm
>> sorry for disturbing, just failed to find it in spec.
>
> Named arguments has been discussed from time to time, but never had  
> the
> support to become a serious proposal. Both proposals here are future
> proof and so I say let's hold off for now. We need to have  
> something to
> talk about when edition4 is done :)

Agreed. Waldemar had these at one point, but we need to finish soon,  
so leaving things out is important -- especially when they can be  
done by object initialiser argument passing and destructuring formal  
parameters.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix

Vassily Gavrilyak
On 3/19/07, Brendan Eich <[hidden email]> wrote:

> On Mar 19, 2007, at 11:10 AM, Jeff Dyer wrote:
>
> >> Thank you for considering this. While I can imagine why this
> >> functionality was disabled in ES1-3 (to protect programmer from
> >> misprints), in typed language typer could be responsible for handling
> >> this, not grammar.
> >> Well, let's wait for Jeff to comment.
> >
> > I'm not sure the type system will help much since 'undefined' will
> > silently convert to a value of most types. An argument list with holes
> > looks like mistake to me. Why not force the user to say what he means?
>
> Agreed. The type checker is an optional strict mode, anyway, so it
> can't help catch mistakes even if hole is not compatible with
> undefined or other typed values.
>
> Note also that holes in arrays mean the property need not be
> allocated, which can save memory and survive hole-preserving
> operations. Not so with actual parameters or the arguments object, at
> least not in any implementation I know of. An arguments object is not
> an Array.
>
> >> Probably named parameters were already considered, in this case I'm
> >> sorry for disturbing, just failed to find it in spec.
> >
> > Named arguments has been discussed from time to time, but never had
> > the
> > support to become a serious proposal. Both proposals here are future
> > proof and so I say let's hold off for now. We need to have
> > something to
> > talk about when edition4 is done :)
>
> Agreed. Waldemar had these at one point, but we need to finish soon,
> so leaving things out is important -- especially when they can be
> done by object initialiser argument passing and destructuring formal
> parameters.
>
> /be
>

Thanks for all the clarifications. Resolving those two would make the
language just perfect for me, but that would be too much :-)
Good luck with deadline and my best wishes!

Regards,
Vassily Gavrilyak
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix

zwetan-3
In reply to this post by Brendan Eich-2
On 3/18/07, Brendan Eich <[hidden email]> wrote:
> The bug fix is clearly talking only about making arguments objects
> delegate to Array.prototype. It's not talking about new syntax to
> allow holes in actual parameter lists.
>

nothing much to add
but glad that this delegating is possible because of the genericity of
those methods :)

cf
"The splice function is intentionally generic; it does not require
that its this value be an Array
object. Therefore it can be transferred to other kinds of objects for
use as a method. Whether the
splice function can be applied successfully to a host object is
implementation-dependent."
etc...

but still out of curiosity,
in a case where someone would want to do the same kind of methods delegation
but with non-generic methods (this value required to be of the original type)
does ES4 offers some way of doing it ?

I'm thinking of reusing Date methods for examples in a "new" classes
like DateTime, TimeSpan, etc...
but Date methods require that the this value be the Date Object.

or another ex, like trying to inherit from the class String on the prototype
cf

class String2
    {
    prototype = new String();

    //etc...
    }

I know that String is final, but if someone want a Char class that is
not provided by default,
but which reuse almost all of the String Object methods, just applying
it to 1 char,
String being final is kind of painfull, a way to circumvent that would
be welcome :).


oups sorry for the HT subject in this thread, or maybe this can be use cases ?

cheers,
zwetan

ps: testing with Tamarin and Flex2 SDK
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

String finality (was: Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix)

Brendan Eich-2
On Mar 19, 2007, at 1:01 PM, zwetan wrote:

> but still out of curiosity,
> in a case where someone would want to do the same kind of methods  
> delegation
> but with non-generic methods (this value required to be of the  
> original type)
> does ES4 offers some way of doing it ?

Bound methods cannot be called on a |this| parameter of the wrong  
type -- they carry their |this| around once extracted (e.g. from a  
class instance).

> I'm thinking of reusing Date methods for examples in a "new" classes
> like DateTime, TimeSpan, etc...
> but Date methods require that the this value be the Date Object.

You can't do this today, and it won't work in ES4.

> or another ex, like trying to inherit from the class String on the  
> prototype

But String's methods are all generic, except for toString and  
valueOf, so you could reuse String's generic methods in several ways  
(by extracting references to them or their static counterparts; by  
subclassing String -- see below; by one-off delegations via .apply or  
equivalent).

> cf
>
> class String2
>     {
>     prototype = new String();
>
>     //etc...
>     }
>
> I know that String is final,

String is final in AS3, but not final in proposed ES4 as of the last  
face-to-face meeting.

Here is the latest plan of record for primitive (string) vs. wrapper  
(String) types:

* Suppose we support primitive types via final class string!, etc.,  
and model wrapping as follows:
     * class string! extends String.
     * The fixed methods of the final primitive class are all  
intrinsic only, not prototype.
     * Which implies that the standard methods of String are only  
prototype [at the time this was written, intrinsic => final -- we are  
revisiting, but backward compatibility does not require intrinsic  
methods in String. /be].
     * Thus we split intrinsic functionality from String and push it  
down into string.
     * “hi”.charAt(0) therefore invokes String.prototype.charAt on  
the string “hi” in the absence of a 'use namespace intrinsic'.
     * If you want speed and not AOP, 'use namespace intrinsic' or  
call “hi”.intrinsic::charAt(0) (or in this case, use indexing).
     * To support “hi”.nosuch === undefined and “hi”.foo = 42 where a  
subsequent "hi".foo results in undefined, we use Jeff’s catchalls  
suggestion [defining get *() {...} and set *() {...} on class  
string], which simulates ES1-3’s wrapping under ToObject
     * Code may freely use string and unless it explicitly uses  
intrinsic, AOP via String.prototype still works.
     * And (thanks to the catchalls) generic get-and-test-against-
undefined (or equivalent) and useless sets still work.

This applies to boolean/Boolean too. Number is different, given the  
several primitive types (int, uint, double, decimal). I'll defer  
getting into Number and let people digest the above.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String finality (was: Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix)

Brendan Eich-2
On Mar 19, 2007, at 1:49 PM, Brendan Eich wrote:

> On Mar 19, 2007, at 1:01 PM, zwetan wrote:
>
>> but still out of curiosity,
>> in a case where someone would want to do the same kind of methods
>> delegation
>> but with non-generic methods (this value required to be of the
>> original type)
>> does ES4 offers some way of doing it ?
>
> Bound methods cannot be called on a |this| parameter of the wrong
> type -- they carry their |this| around once extracted (e.g. from a
> class instance).

I should have distinguished the case of an instance-bound method,  
where |this| carried along by the method closure, from a type-
constrained |this| method, where you could extract and call on a  
different instance, but the type would still be constrained to be a  
subtype of the type from which you extracted the method.

We allow both cases to be expressed. To see both instance-bound and  
type-constrained |this| methods, consider this class:

class C {
   public var x;
   function C(x) : x = x { }

   // An instance-bound class method -- a "fixture"
   // (DontEnum/DontDelete/ReadOnly and type-constrained
   // by its function type).
   function m() { return x; }

   // An unbound prototype method with type-constrained |this|.
   prototype function p(this: {x:*}) { return this.x; }
};

let c = new C(42);
let m = c.m;
print(m());                   // prints 42

print(c.p());                 // prints 42 also

let o = {m: m, x:43};
print(o.m());                // prints 42 still

o.m = c.p;
print(o.m());                // prints 43

So class instance methods are instance-this-bound. Prototype methods  
(among other features) are unbound and by default their |this|  
parameter is not type-constrained. But you can write (this:T at the  
start of a formal parameter list or function type signature to  
constrain the type of |this|.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

instance vs. prototype [was: String finality (was: Re: ARGUMENTS.SHOULD.BE.ARRAY bug-fix)]

P T Withington
On 2007-03-19, at 17:08 EDT, Brendan Eich wrote:

> instance-bound and
> type-constrained |this| methods

<lightbulb />

I have puzzled over the difference between defining an instance  
method and a prototype method, maybe I finally see the light.  What  
you pointed out about the binding of `this` in the former and not the  
latter was not obvious to me from the spec.  Should it have been?  
Are there other differences?  What about instance vs. prototype for  
`var`?  (Other than that you can dynamically change the prototype  
value.)

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss