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



Reply via email to