>Really, you want to tie it to the attempt to deserialize a Vector, not the use >of Vector (or even VectorColletion) in any app, right? You could subclass the >known serialization points and hook their initializers. If you >go low-level, >you should have to deal with registration, but if you use >VectorSerializableByteArray instead of ByteArray, maybe that's when it gets >more convenient?
If someone does any serialization and deserialization of a Vector today, it is broken. This includes things like ByteArray and things like RemoteObject. IMO, this is a Flash Player bug, but they won't let me fix that code. So, how does that work when someone sends a Vector over a RemoteObject call? Do they now need to extend RemoteObject to ensure it serializes properly? Vector is a built in type. Why should it work differently? That doesn't seem to track with what a user would expect of the framework to me. So, personally, if I can serialize a String today into a ByteArray without registration and I can serialize an Array without doing registration, then it seems to me I should be able to serialize a Vector of Strings without doing registration of my own. Incidentally, this is what we are talking about: registerClassAlias( "Boolean", Boolean ); registerClassAlias( "int", int ); registerClassAlias( "Number", Number ); registerClassAlias( "String", String ); registerClassAlias( "uint", uint ); registerClassAlias( "Array", Array ); registerClassAlias( "Date", Date ); registerClassAlias( "Vector", Vector ); I ran it in a loop (in debug mode) on my machine 10,000 times which took a total of 31ms. I am not for inflating startup times either, but I am thinking the ~0.0031ms minus the loop time (which I am guessing is the balance) might not be noticed in the average app. Mike
