ES4 draft: Vector

Jon Zeppieri 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
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.

Agreed.

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

-Jon

>
>
>  --lars
>  _______________________________________________
>  Es4-discuss mailing list
>  Es4-discuss at mozilla.org
>  https://mail.mozilla.org/listinfo/es4-discuss
>
>



More information about the Es4-discuss mailing list