Minor oversight, but wasted memory.

I observe that this program: var a = new <int> [1,2,3] a.foobar = "hello, there" print(a.foobar) results in this error: ReferenceError: Error #1056: Cannot create property foobar on __AS3__.vec.Vector.<int>. at global$init() yet I'm confused because in Vector.as I see this: dynamic final class Vector$int which suggests I should definitely be allowed to create properties like that. Are we sure the bug here is that a hashtable is created needlessly, and not rather that the vector won't accept entries into that hashtable, though it should? (The October 2007 draft of ES4 allows for arbitrary dynamic properties named by non-numbers.)

I don't know the history, but as a guess, perhaps "dynamic" is present simply to stop ASC's strict mode from complaining about [] access? IIUC, the AS3 version of Vector was explicitly designed to accept only uint property names... adding Erik Tierney, who did most of the work on this.

access of properties through [] never causes strict mode errors in ASC. If I remember correctly, I made Vector dynamic because it was dynamic in the ES4 proposal. I don't remember doing any work to disallow non-numeric dynamic properties - it is probably a bug if the ES4 proposal allows it.

Hmm... well, regardless of the ES4 spec (which is irrelevant now anyway), it appears that de facto Vector<> code allows only for uint properties; no reason to expand that now. (And the comment about the hashtable being unnecessary stands.)

As the author of the ES4 library spec, and probably most of the ES4 code implementing that spec, I am reasonably sure that it was not accidental or a bug for ES4 to allow that. Consider that dynamic properties can be added to Vector's prototype object, so it's not like any reasonable implementation of ES4 could flag an error for the reference v.foo for any known vector v. (AS3's strict mode is different, of course.) Also, Vector has to be 'dynamic' because anything else would mean you couldn't even add numeric properties. And it's a strange 'dynamic' that allows one kind of new property and not another, for no good reason. I'm not saying we should change AS3, but ES4 is more consistent here, and by design.

(In reply to comment #6) > I'm not saying we should change AS3, but ES4 is more consistent here, and by > design. Yeah, no argument -- my point is simply that if Vector currently only allows uint properties (which appears to be the case): (1) we can't change that without versioning (2) Hashtable is unnecessary (It's a trivial savings that may not be worth bothering with, as an always-empty hashtable is tiny...)

Given that the language is what it is, and there is no deep need to allow non-numeric-named properties on Vector, getting rid of the superflous Hashtable is a good idea, even if the savings is small: A major case for Vector in graphics processing will be as short vectors of Vector.<float4>, notably to represent 4x4 matrices of float. There may be many of those, and reducing the cost of each will be useful.