> 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 usability hazard. I guess not (although I still think it is). Do
we agree to shallow assignments?
class C { public var x : string; public function m(x) { return x} }
c = new C
c.x = 42;
function F() {}
f = new F
f.x = 43; // doesn't affect c
f.m() -> 42? // |this| is c?
>
> typein:10: TypeError: Date.prototype.setTime called on incompatible
> Object
Is there other implications of having instances (of function constructors)
of classes instead of Object for maintaining backwards compatibility besides
primitive's method calls? Couldn't this be fixed easily with:
setTime = function() {
if (this.__proto__ != Date.prototype) throw IncompatibleError
...
}
> Wanting a type error instead of a conversion is a separate topic, so
> let's talk about it in another thread. See also
Sorry, I didn't want to breach that subject at all, I was just noting that
my example wasn't perfectly correct in how the fixtures would react.
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
