On 3/5/08, Lars Hansen <[EMAIL PROTECTED]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es4-discuss > > _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
