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 implicit conversion).
This behavior is incorrect. For compatibility with ES3, property
writes must be shallow.
Agreed, but the question is: how? If you say that f.hasOwnProperty
('x'), then what is the type constraint on that property's value? If
it is String, then how is it implemented given that new F creates an
Object instance, not a C instance?
One could imagine a fixture being added to each Object instance
created by new F. It would make the type of f be {x:String}, which is
compatible with C assuming you put 'public' in front of 'var
x' (that's necessary, otherwise the x in c is in C's internal
namespace -- please correct me if I have this wrong).
What's not allowed is an unconstrained slot on f -- that would break
type safety for methods of C that count on x being a String. What
also seems hard to believe in is some magic getter/setter pair in c
(f.__proto__) that lets x be stored in each instance (f) but enforces
the type constraint.
So when you wrote "This behavior is incorrect", did you have in mind
a fixture per instance, created on demand when assigning ("writes
must be shallow") to x where f.__proto__.x is a fixture defined by C?
I.e., a copy-on-write fixture due to the class of f differing (and
lacking any public::x of its own) from the class of c?
If you want x to be a delegated and override-able "plain old"
property, not a fixture, declare C thus:
class C { prototype var x : String; }
To be clear, in the example above this would put a expando property
‘x’ on ‘f.__proto__.__proto__’.
Yes, but it could be shadowed in f instances, inheriting the type
constraint.
See my comment before my last one. Making prototypes more like
classes would make them less flexible, more complicated, and
duplicate functionality that is already available. I don’t see the
point, but maybe I’m missing the use case.
Using functions as extra constructors may be a use-case, but the
primary problem is definitional: given functions and classes, what
*should* happen in Kris's example, and how should it be specified/
reference-implemented? Copy-on-write fixtures are a new thing under
our Sun, it seems to me.
/be
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
