On 05-04-2012, at 23:14, Michael A. Labriola wrote:
>> 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 > Please add this to the compiler. It's a very good suggestion and making the use of flex more consistent. The costs are very low so i don't see any problem, just advantages. Met vriendelijke groet, Arnoud Bos Artim interactive T +31 6 246 40 216 E arn...@artim-interactive.nl