ES4 draft: Vector
lhansen at adobe.com
Wed Mar 5 17:16:32 PST 2008
> -----Original Message-----
> From: zeppieri at gmail.com [mailto:zeppieri at gmail.com] On
> Behalf Of Jon Zeppieri
> Sent: 5. mars 2008 15:52
> To: Lars Hansen
> Cc: es4-discuss at mozilla.org
> Subject: Re: ES4 draft: Vector
> On 3/5/08, Lars Hansen <lhansen at adobe.com> wrote:
> > > So, why a read/write, rather than a read-only, 'fixed' property?
> > It was my hunch when I designed that feature that code that uses
> > fixed-length vectors wants to be able to catch errors most of the
> > time, but also does not want to be stuck in the straightjacket
> > that a settable-but-not-resettable fixedness property creates,
> > leaving it unable to extend the vector in place after making it
> > fixed.
> I don't think I've ever encountered this feature in another
It takes an unsual mind to think of these things :-P
> I've seen the following:
> - Languages like Java that have a distinction between
> fixed-length arrays and variable length ones
> - Dependently typed languages that allow you to express the
> type "Array with length N"
> - Languages that provide immutable arrays (which goes beyond
> the fixed-length guarantee) in addition to mutable ones
That's something we're missing but could have had.
> But I haven't seen vectors that can change from fixed- to
> variable-length and vice versa. So I guess I'm a bit
> skeptical of the demand for this feature. I'm trying to
> think of tasks where I need a vector to be a certain length
> for part of the computation and a different length for a
> different part -- and where I would also be upset to be
> forced to create a new vector (and copy into it) in order to
> accomplish that. (Of course, the "new vector + copy" is a
> simple invocation of the Vector constructor as a function.)
Note, the Vector class called as a function does not create a new
vector if its input is a vector. The prose is wrong in the draft,
but the code is right.
There probably should be copy() method on the Vector class.
> Obviously, we can save the cost of the copy if we have the 'fixed'
> flag, but we don't get the benefit of having a nice invariant.
What's the nice invariant?
> Incidentally, since I brought up immutable arrays, above:
> intrinsic methods make it impossible to enforce immutability
> via subclassing, right? You could create an immutable
> sequence type through delegation, but not simply by
> overriding the mutators. Or is there a way to make the
> intrinsics unavailable publicly?
I don't understand the question. There is nothing magic about the
intrinsic methods; if you override them all with versions that
prohibit updating, then you should have an immutable array. The
prototype methods delegate to the intrinsic methods on the "this"
I'm open to the possibility that the design with the "fixed"
property is baroque and not worth the bother. (That it is
unusual doesn't bother me.) I do feel it's important to be able
to provide error checking for arrays; it's way too easy in ES3
to write out of bounds without getting any sort of error.
It may be that a set-but-not-reset property is an alternative,
or that the length must be provided to the constructor and that
it is fixed after that. Both seem less flexible than the current
design and I'm not sure what the benefits would really be (apart
from safety against "hostile" code, but then you wouldn't be
working in ECMAScript).
More information about the Es4-discuss