incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Labriola" <>
Subject RE: RFC - additional registerClassAlias
Date Thu, 05 Apr 2012 21:14:45 GMT
>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.


View raw message