ES4 draft: Vector

Jon Zeppieri jaz at
Wed Mar 5 17:58:43 PST 2008

On 3/5/08, Lars Hansen <lhansen at> 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
don't trust.

>  > 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"
>  object.

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.


>  --lars
>  _______________________________________________
>  Es4-discuss mailing list
>  Es4-discuss at

More information about the Es4-discuss mailing list