On Jul 21, 2007, at 7:13 AM, Kris Zyp wrote:
> So does this mean that the verdict has been reached for whether or
> not new
> objects from function constructors can be classes?
I pointed out that ES3 does not do what you seem to want here
(functions as auxiliary constructors for classes). In
: "Brendan Eich" <[EMAIL PROTECTED]>
To: "Kris Zyp" <[EMAIL PROTECTED]>
Cc: ; "Jeff Dyer" <[EMAIL PROTECTED]>
Sent: Friday, July 20, 2007 5:37 PM
Subject: Re: delegating to typed objects
> On Jul 10, 2007, at 9:20 AM, Kris Zyp wrote:
>
>>&
On Jul 10, 2007, at 9:20 AM, Kris Zyp wrote:
>> The class methods can't be extracted or called without this
>> binding to
>> the object from which they were extracted or in which they were
>> found, so
>> there's no type check. From the reference implementation:
> I thought we had agreed tha
> The class methods can't be extracted or called without this binding to
> the object from which they were extracted or in which they were found, so
> there's no type check. From the reference implementation:
I thought we had agreed that |this| being c instead of f in f.m() was too
much of a u
On Jul 10, 2007, at 8:21 AM, Kris Zyp wrote:
> Because it's possible to violate the type constraints on fixtures in
> the non-subclass object created by the function constructor?
> Not if the instance of F is a instance of C.
>
> 1. Classes do not constrain types, have to check everything...
>
> C
Because it's possible to violate the type constraints on fixtures in
the non-subclass object created by the function constructor?
Not if the instance of F is a instance of C.
1. Classes do not constrain types, have to check everything...
>
>
Certainly don't want that. However, checking to
On Jul 9, 2007, at 9:09 PM, Kris Zyp wrote:
> I think it seems worth considering what a programmer is intending
> if writes
> a function and defines a prototype for it. This is an explicit
> action to
> create objects that inherit from the prototype object. If a user has
> specifically written
gt;
To: "Kris Zyp" <[EMAIL PROTECTED]>
Cc: ; "Jeff Dyer" <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2007 5:00 PM
Subject: Re: delegating to typed objects
> On Jul 9, 2007, at 4:51 PM, Kris Zyp wrote:
>
>> You are right, it doesn't work for a Date, but
On Jul 9, 2007, at 4:51 PM, Kris Zyp wrote:
> You are right, it doesn't work for a Date, but it does work on an
> Array.
Only if you don't call toString or toLocaleString.
Most Array and String prototype methods are intentionally generic.
Too bad we didn't generalize this all over the place
You are right, it doesn't work for a Date, but it does work on an Array. The
incompatibility of calling setTime on the Date instance seems to have more
to do with the natural inclination to make primitives classes "final" (I am
not sure if they are in ES4, but in Java they are final) than class me
On Jul 9, 2007, at 4:40 PM, Brendan Eich wrote:
>> And it has burned me that I could not do that. I wanted to write an
>> 'annotated string' and couldn't because of exactly this restriction.
>> Will I be able to subclass built-in types?
>
> Subclass, yes -- provided the superclass is not final.
On Jul 9, 2007, at 4:32 PM, P T Withington wrote:
> On 2007-07-09, at 19:16 EDT, Brendan Eich wrote:
>
>> Having thought about 1 more, I'd like to point out that it's *not*
>> what ES3 does:
>>
>> js> function F(){}
>> js> F.prototype = d = new Date
>> js> f = new F
>> js> f.__proto__ === d
>> tru
On 2007-07-09, at 19:16 EDT, Brendan Eich wrote:
> Having thought about 1 more, I'd like to point out that it's *not*
> what ES3 does:
>
> js> function F(){}
> js> F.prototype = d = new Date
> js> f = new F
> js> f.__proto__ === d
> true
> js> f.setTime(0)
> typein:10: TypeError: Date.prototype.
On Jul 9, 2007, at 4:16 PM, Brendan Eich wrote:
> I think we have only two courses:
>
> 1. Kris's proposal to make F construct instances of C. If C is not
> dynamic, these instances can't be decorated with expandos by (new
> F) or its callers.
>
> 2. Your proposal to avoid any magic implicatio
On Jul 9, 2007, at 3:22 PM, Jeff Dyer wrote:
On 7/9/07 2:42 PM, Kris Zyp wrote:
It seems to me that transfering bound methods to the function
instances makes the situation equally confusing:
Now if write:
class C { var x : String; function m() : String { return this.x }}
c = new C;
function
On Jul 9, 2007, at 2:19 PM, Jeff Dyer wrote:
See my comments above. There is no need for copy on write
fixtures, just a plain old expando on ‘f’ for ‘x’.
Ok, I see your point.
If you want type guarantees, use classes.
Rather, use classes or structural types only, not constructor
functi
Is class like inheritance just too much of an implementation burden? Is it
hard for new F objects to be an instantiation of C like subtypes of C would
be? It stills seems to me consistency with the behavior of the rest of ES
would suggest class like inheritance. If an error was to be thrown, where
On 7/9/07 2:42 PM, Kris Zyp wrote:
> It seems to me that transfering bound methods to the function instances makes
> the situation equally confusing:
> Now if write:
> class C { var x : String; function m() : String { return this.x }}
> c = new C;
> function F() {}
> F.prototype=c;
> f = new F;
It seems to me that transfering bound methods to the function instances
makes the situation equally confusing:
Now if write:
class C { var x : String; function m() : String { return this.x }}
c = new C;
function F() {}
F.prototype=c;
f = new F; // f.__proto__ = c
f.x =4;
f.m() -> ???
A Transferred
On 7/9/07 1:17 PM, Brendan Eich wrote:
> On Jul 9, 2007, at 12:10 PM, Jeff Dyer wrote:
>
class C { var x : String; }
c = new C;
function F() {}
F.prototype=c;
f = new F; // f.__proto__ = c
f.x =4;
If you do this c.x now equals "4", tha
On Jul 9, 2007, at 12:10 PM, Jeff Dyer wrote:
class C { var x : String; }
c = new C;
function F() {}
F.prototype=c;
f = new F; // f.__proto__ = c
f.x =4;
If you do this c.x now equals "4", that is the value is not set
in f, but it goes up the prototype chain and sets 4 into x (and
does impl
On 7/2/07 1:29 PM, Brendan Eich wrote:
> On Jul 2, 2007, at 9:21 AM, Kris Zyp wrote:
>
>> It appears (at least in the reference implementation) that one there is an
>> object that has a delegate object that is a typed object, that overwriting
>> members in the top instance is sometimes not possi
To me it makes more sense to have functions constructors creating new
instances of classes as you described. It seems more consistent having
prototype chains and class inheritance being in sync as much as possible, as
they are both forms of inheritance. Right now, if an object is an instance
of a
On Jul 2, 2007, at 9:21 AM, Kris Zyp wrote:
It appears (at least in the reference implementation) that one
there is an object that has a delegate object that is a typed
object, that overwriting members in the top instance is sometimes
not possible. For example:
class C { var x : String; }
It appears (at least in the reference implementation) that one there is an
object that has a delegate object that is a typed object, that overwriting
members in the top instance is sometimes not possible. For example:
class C { var x : String; }
c = new C;
function F() {}
F.prototype=c;
f = new F;
25 matches
Mail list logo
