ES4 draft: Vector
jaz at bu.edu
Wed Mar 5 17:58:43 PST 2008
On 3/5/08, Lars Hansen <lhansen at adobe.com> wrote:
> 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.
It's identical to a slice() with no specified parameters.
> > 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?
An actually fixed length. The proposed 'fixed' field is a debugging
aid. A read-only version, on the other hand, is a guarantee that
holds even if you hand your vector off to code you didn't write and
> > 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"
Yeah, my mistake. For some reason, I was under the impression that
intrinsic methods couldn't be overridden.
> 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).
Mingling with others' code is something that already happens on the
web; consider how (legitimate) services get around the cross-site
restrictions browsers implement. I can't imagine security in ES is
going to get less important.
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
More information about the Es4-discuss