You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by "Michael A. Labriola" <la...@digitalprimates.net> on 2012/04/05 22:55:25 UTC
RFC - additional registerClassAlias
Okay, now that we almost have a VectorCollection, we have a bridge to cross... Serialization or actually Deserialization.
If I serialize this Vector:
var vector:Vector.<String> = new Vector.<String>();
var vector2:Vector.<String>;
var ba:ByteArray = new ByteArray();
ba.writeObject( vector );
All is well. However, when I deserialize it, I will receive a crash:
ba.position = 0;
vector2 = ba.readObject();
TypeError: Error #1034: Type Coercion failed: cannot convert __AS3__.vec::Vector.<Object>@620f061 to __AS3__.vec.Vector.<String>.
That is because, when it attempt to deserialize the ByteArray, it does so as a Vector of type Object as it does not properly recognize the alias of the type of the Vector's contents. Now, for fun, if I first register a class alias for String:
registerClassAlias( "String", String );
All works properly, as the alias of String is looked up and properly deserialized. So, given this little bit of frustration. What would everyone think about further modifying the compiler to add registrations for the basic types in the startup of Flex apps? In the _ProjectName_FlexInit-generated.as, the compiler already adds to registerClassAlias calls for ObjectProxy to work around some memory leak issues. We could add registrations for the basic types right here. This would mean the Vectors, and hence VectorCollection and VectorList instance, would deserialize as expected in our Flex apps.
This is the first of many compiler changes I have made and want to discuss.
Thoughts?
Mike
digital primates (r)
Michael Labriola
labriola@digitalprimates.net<ma...@digitalprimates.net>
tel: +1.773.693.7800 x206
fax: +1.773.409.9251
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Anyway, I guess what I'm trying to say is - what is vector serialization good for and where would it be used? How much juice are we going to get for the squeeze?
Those of us that do use it have a working version for executing 5 lines of code which are now only executed if you use VectorList.
Mike
Re: RFC - additional registerClassAlias
Posted by Rick Winscot <ri...@gmail.com>.
Serialization has always been a troublesome topic... I'm wondering if
we shouldn't be looking more at JSON now that it's baked into Flash
Player. Going that direction may make Flex more valuable with RESTful
services. Maybe.
Anyway, I guess what I'm trying to say is - what is vector
serialization good for and where would it be used? How much juice are
we going to get for the squeeze?
R
On Sun, Apr 8, 2012 at 8:13 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> HI,
>
>> Okay, now that we almost have a VectorCollection, we have a bridge to cross... Serialization or actually Deserialization.
>
> Perhaps a way to get around this is instead of serialising the vector is to serialise an array representing the vector.
>
> Something like so (not tested so not 100% sure if it will work).
> public function readExternal(input:IDataInput):void
> {
> source = new Vector.<*>(input.readObject());
> }
>
> public function writeExternal(output:IDataOutput):void
> {
> output.writeObject(toArray());
> }
>
> I seem to recall running into the same issue with ArrayCollection a while back. I'll see if I can dig up the code and remember what the exact issue was.
>
> Thanks
> Justin
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Fair enough. I had thought that Vector<*>([]) would get the type from the first element of the array but I guess not.
Yeh, I wish there was an easier answer here. The point Oleg brings up are worrisome for the whole idea I had too
Re: RFC - additional registerClassAlias
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> Then we lose all type information and if you serialize a variable and deserialize to the same variable you get a crash as the types no longer match.
Fair enough. I had thought that Vector<*>([]) would get the type from the first element of the array but I guess not.
Thanks,
Justin
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Perhaps a way to get around this is instead of serialising the vector is to serialise an array representing the vector.
Then we lose all type information and if you serialize a variable and deserialize to the same variable you get a crash as the types no longer match.
Mike
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Perhaps a way to get around this is instead of serialising the vector is to serialise an array representing the vector.
Also, it is worth pointing out that the Vector serializes fine, it just comes back with a different type if you don't do those registerClassAlias statements. So, effectively, this isn't much different than the Array.
Mike
Re: RFC - additional registerClassAlias
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> Okay, now that we almost have a VectorCollection, we have a bridge to cross... Serialization or actually Deserialization.
Perhaps a way to get around this is instead of serialising the vector is to serialise an array representing the vector.
Something like so (not tested so not 100% sure if it will work).
public function readExternal(input:IDataInput):void
{
source = new Vector.<*>(input.readObject());
}
public function writeExternal(output:IDataOutput):void
{
output.writeObject(toArray());
}
I seem to recall running into the same issue with ArrayCollection a while back. I'll see if I can dig up the code and remember what the exact issue was.
Thanks
Justin
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>For now, are you okay with adding this to VectorList and then going from there?
I could do this by noticing the type of the Vector when a VectorList is instantiated or when you attempt to serialize, but there is a catch. If I receive a Vector from the server before the first time a VectorList is instantiated, the serialization will fail. That's a crappy thing to debug as multiple paths through an application could yield different results.
I could also do it as a static initializer of the VectorList class so that the first time the class is touched the register happens. Still not ideal, but at least you would only pay if you used the VectorList.
Thoughts?
Mike
Re: RFC - additional registerClassAlias
Posted by Alex Harui <ah...@adobe.com>.
On 4/5/12 3:04 PM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
> For now, are you okay with
> adding this to VectorList and then going from there?
Sounds reasonable.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Why should built-ins be auto-registered, but my custom classes are not (without doing [RemoteClass])?
Well, I would say they kind of are. You can serialize and deserialize a String without doing a register.
>This is one of the places I do wish we could get a VM change, but we can't and will have to live some with imperfections.
Agreed
>So, I'm asking you to think about a PAYG way of doing this before making every app pay.
Fair enough. The thing I am trying to avoid is just 50 users solving this problem 52 different ways. So many apps I see have a variation of this workaround in it. To me, that's kind of silly. For now, are you okay with adding this to VectorList and then going from there?
Mike
Re: RFC - additional registerClassAlias
Posted by Omar Gonzalez <s9...@apache.org>.
FxByteArray.as anyone?
*ducks and covers*
--
Omar Gonzalez
s9tpepper@apache.org
Re: RFC - additional registerClassAlias
Posted by Left Right <ol...@gmail.com>.
Well, the whole thing about how serialization in Flash works is moot... but
it's not anything that we could help, even if we wanted to very much.
Probably, it should be made clear that this is not just serialization into
some amorphous format, especially because JavaScript, if we will ever get
there, will need it's own AMF implementation (which is actually easy!).
There are other problems current model doesn't solve (because it was
blind-copied from Java, and it just works bad there too). Anyway, recursive
serialization of IExternalizables is a pain - you can't really do this
using just the built-in API, chances are, that if that is what you need,
you will write AMF serializer on your own, in AS3 :) Funny, eh? Besides, if
you have a more complex object to serialize, where several IExternalizables
plug in, you won't be able to take advantage of AMF format because it, when
writing these objects is not aware of the context, where they will be
placed, and it will not "optimize" the parcel after the last write.
Essentially, in order to have effective AMF serializer, the existing native
API are lacking. You _always_ need the context, where you write your
objects. Always as in any non-trivial situation. Alternatively, you can do
it in two layers - similarly to how tar is usually used with gzip (tar
creates single piece file, while gzip compresses the whole thing). Present
AMF serialization model in this light resembles that of zip, where both the
archiving and compressing done by single program file by file causing bad
reuse rate for when you are compressing more then one file.
Now, there's another aspect. Framework prescribes serializing views!
Against all odds you serialize the collection's view (and you forget about
how it was sorted and the bookmarks and all that). This is a bad practice.
No one, ever, should have serialized ArrayCollection, ObjectProxy and other
*abominations* :).
Yet another problem is with [RemoteClass] meta. It
- makes the process almost impossible to debug (w/o in-depth knowledge of
the framework templates you wouldn't know where the code registering alias
goes). This created a whole lot of mythology and superstitions.
- you can't control when it happens (effectively, you don't even know, but
assume it's before the application even starts - which is of course wrong).
All that said - I'd be for making the mechanism more transparent, if at all
taking any steps in order to build on top of what built-in functions have
to offer. But if I was to design the API for this, it would be something
like:
AMFContext.createContext() :: AMFContext;
AMFContext.registerAlias(Class, "alias") :: void;
AMFContext.append(object) :: void;
AMFContext.onSerialize(function(Class), data) :: void;
AMFContext.onDeserialize(function(Class), data) :: void;
AMFContext.flush() :: ByteArray;
So, while we add more classes *sigh*, we could actually reduce the size it
takes on the wire, when serializing everything in one go, instead of doing
it item at once. But in this way we avoid global handling, security
problems with who registers alias where and so on...
Well, just brainstorming :)
Best.
Oleg
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>I'm afraid that's what we can do, given only the AS side of things. I reckon there must be a bug for that in Flash player bug base, but it's too tedious to search it since it moved from JIRA :) so I can't find it.
My concern is just making Vector different. I dislike the ideal of having a Serializeable Vector only because we are now asking people to avoid a built in type in situations where we serialize. I just don't like the inconsistency of being able to use the other built-ins effectively.
Mike
Re: RFC - additional registerClassAlias
Posted by Left Right <ol...@gmail.com>.
There are several undocumented AMF types, Vector.<T> is one of them,
however it is only partially implemented (it's also known as "type 13"
because 13 eventually is the value of the tag produced in AMF).
It is only half-baked because it doesn't preserve the runtime type of the
vector.
There are some positive and negative sides to consider when creating custom
serialization of vectors. Vectors are dense, which means that they are
_easier_ to serialize then ECMA arrays (the later consists of two
compartments, one for the dense part and another for the sparse part). I
would go about vector serialization like this: create a serializer method
that writes the IExternalizable type which would contain the record
generated from vector and one field for the type - so we use the same
routine for serialization of all vectors.
Why not use arrays - few people know, but arrays pose a danger of "memory
asplodes" attack :) since in many languages (such as, notably, Java), when
arrays are deserialized the created array instance will be dense. So, this
code:
var array:Array = [];
array[int.MAX_VALUE] = "hello";
connection.send("service", array);
will cause on the Java end something like this:
new ArrayList(0x7FFFFFFF);
which would usually bring down the unsuspecting Java server.
With vectors you can't do it, or rather it will explode on the client side.
The problem is many AMF implementation are incomplete in that they don't
treat IExternalizables in any way... or, selectively.
This problem is also repeated in Dictionary class, which is also partially
implemented in AMF, but has bugs pertaining to item deletion.
I'm afraid that's what we can do, given only the AS side of things. I
reckon there must be a bug for that in Flash player bug base, but it's too
tedious to search it since it moved from JIRA :) so I can't find it.
Best.
Oleg
Re: RFC - additional registerClassAlias
Posted by Left Right <ol...@gmail.com>.
thoughtfulness -> thoughtless (sorry, I typoed).
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>What I suggest be done.
>- Pressure Adobe to release AMF 3.1 spec and implement it in the player in the way that references inside vectors and dictionaries count towards total >count. Remove undocumented features from AMF 3.0, so that conforming implementation wouldn't have the problem of running into something they >neither can understand nor skip.
>- Pressure Adobe to change the AMF serialization API in a way it stops being global.
>- For the time being, it is possible to build the model for serialization / deserialization, which is not global, which would only register aliases for the >writing / reading operation, and unregister them after the operation finishes. I've posted the API, as I would like them to be before.
Oleg,
Thanks for this. Will write up some thoughts tomorrow.
Mike
Re: RFC - additional registerClassAlias
Posted by Left Right <ol...@gmail.com>.
As I re-read now my replies, I see how they are a little hectic, and the
important thing probably skipped your attention. I will first try to
explain what is the problem with vectors when they are serialized /
deserialized, then I will "reflect" on the current serialization mechanism
in the flash player, and then to the framework. Then, some suggested
changes.
1. When reading AMF format, the parser needs to maintain 3 tables:
- data table: any string, number, byte array is referenced in this table if
it is more then 2 bytes long, this is done so the objects can be reused.
- object-properties table stores the descriptions of sealed classes already
[de]serialized, so that any two objects of the same type would not send
their type description.
- object-references table stores references to already serialized objects,
similar to the first table it helps reusing objects already serialized
(this is why recursive and many-to-many relations may be serialized).
Vector and Dictionary are not parts of the AMF 3.0 format. Adobe
implemented them in the player, but, obviously, had tried to not to break
all other implementations which knew how to read AMF 3.0 as documented.
Vector uses it's special format for writing it's data, which other
implementations cannot read (possibly Adobe's own BlazeDS can, but not
anyone else that I know of). If objects inside vector were counted towards
the references inside the general references table, if an AMF package
containing a vector was to be read by an implementation unaware of vectors
(and not being able to count the references inside vector), the references
table would break. This means that today using vectors in AMF is a big
no-no, because it is sub-optimal. It is an experimental feature, but if you
care about traffic utilization you should not do it. Same thing with
dictionaries - no conforming implementation knows how to read them, that's
why references inside dictionaries don't count towards the general
reference count and are serialized every time in full volume.
2. The design of AMF serialization API in Flash player is short-sighted.
There are two major problems with it.
a. It is unaware of security sandboxes, (later versions tried to fix this,
but they realized that the "fix" was both incomplete and broke a lot of
other things, so they sort of rolled it back with a warning). Originally,
aliases were registered universally for all sandboxes, this later appeared
to be a problem, as if any loaded SWF, that had to be unloaded would
register it's own aliases, that SWF would fail to unload. The original
"fix" suggested that classes be registered each for the sandbox it comes
from. This broke a lot of code that relied on the old functionality. So,
today, the player is trying to guess what to do - if the call to
deserialize a class doesn't find an alias in the current sandbox, it will
look in other sandboxes too. Which, in my opinion, is even worse, because
it turns the testing of this feature into a nightmare.
b. Player's serialization API make it impossible to efficiently serialize
IExternalizable objects. This is so because the reference tables are not
accessible to whoever is trying to write AMF object on their own. So, even
if you are serializing two IExternalizable objects that reference the same
object, you have no simple way to make sure the referenced object is
written only once. This, for example, will cause that if your value object
has two ArrayCollections that contain mostly the same items, concatenating
two collections before sending them will yield significantly smaller file,
then if you left them be two separate collections.
c. The API designed to be global. They suffer from all the same problems
typical for global variables - random parts of the application can set or
unset them and in complex situations you have no idea what is going on in
your code.
3. Framework code (which is, frankly, none of my business, but in case you
wanted to know...) generates from [RemoteClass] meta ridiculously bad code
in the FlexInit class that registers all aliases in one go. I usually
advise against using this meta because of the following reasons:
a. It makes the process impossible to control and very problematic to debug.
b. You will not have any pointer in your code to the alias, for which the
class has been registered, so, if later you wanted to find the alias w/o
knowing what was the aliased class, or, if you eventually registered
another class with the same alias - you can't do it.
Framework code uses RemoteMessage and few more other classes that the
implementation of AMF 3.0 has to know how to handle, even though these
classes aren't part of the format.
===
What I suggest be done.
- Pressure Adobe to release AMF 3.1 spec and implement it in the player in
the way that references inside vectors and dictionaries count towards total
count. Remove undocumented features from AMF 3.0, so that conforming
implementation wouldn't have the problem of running into something they
neither can understand nor skip.
- Pressure Adobe to change the AMF serialization API in a way it stops
being global.
- For the time being, it is possible to build the model for serialization /
deserialization, which is not global, which would only register aliases for
the writing / reading operation, and unregister them after the operation
finishes. I've posted the API, as I would like them to be before.
* * *
I know that my view of the framework many people find too controversial,
that's why I put it separately:
- Make ArrayCollecion not serializable by default, likewise ObjectProxy -
the reason being that no one should use them to serialize the data they
represent. If you wanted to properly serialize the data presentation,
which, for example, ArrayCollection is, you would also need to serialize
bookmarks, cursors positions, sorting order, filtering etc. The current
serialization _only_ serializes the data, which is wrong both factually (as
lots of data is lost) and in terms of design (if you wanted to serialize
the data - go on, and serialize the data, why are you abusing the view
instead?).
- Make it a rule that the framework never uses any classes not described in
AMF spec to send it's RPC messages. The later, when neglected, imposes
idiotic limitations on implementations and also caused conforming
implementations to do a lot of hardcoded silly things, like, for example,
automatically register an alias for ArrayCollection. This means that
RemoteMessage class needs to be deprecated and replaced by just generic
object, or array, other Remote* things which are sent over the wire need
that too. This was a thoughtfulness design by Adobe targeting their
proprietary data services, which makes no sense if we want to design a
really functional and friendly product.
Best.
Oleg
Re: RFC - additional registerClassAlias
Posted by Arnoud Bos <ar...@artim-interactive.nl>.
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 arnoud@artim-interactive.nl
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>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.
And yes, I already agree that if I make this argument 10,000 times I am adding 31ms :)
Mike
Re: RFC - additional registerClassAlias
Posted by Alex Harui <ah...@adobe.com>.
On 4/5/12 2:14 PM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
> 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?
RemoteObject could have an additional resultFormat that tells you to run
those aliases.
> Vector is a built in type. Why should it work differently?
Why should built-ins be auto-registered, but my custom classes are not
(without doing [RemoteClass])?
> 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.
There are other problems with the Vector implementation besides this one.
This is one of the places I do wish we could get a VM change, but we can't
and will have to live some with imperfections.
I believe you are a proponent of "pay-as-you-go" in Flex and having the
compiler always generate this code is not PAYG. If you want to add a
compiler option, that might be ok too. I just believe that, if you write
low-level AS3 code, it should be exactly what you wrote and not have other
stuff added in. Also, having spent the last several years trying to
optimize Flex, one of the problems is that there are 1000's of little
helpful code snippets like this in Flex and each take less than 1ms. But
after you add them up, you've add 500ms to the startup time of your app.
So, I'm asking you to think about a PAYG way of doing this before making
every app pay.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>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
Re: RFC - additional registerClassAlias
Posted by Alex Harui <ah...@adobe.com>.
On 4/5/12 2:01 PM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
>> I would put the additional registration calls in the class initializer for
>> VectorCollection. If you aren't using it, you shouldn't have to pay for the
>> registration.
>
> Alex,
>
> This affects Vector, not just VectorCollection. How do I add the registrations
> to the initializer for Vector?
>
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?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: RFC - additional registerClassAlias
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>I would put the additional registration calls in the class initializer for VectorCollection. If you aren't using it, you shouldn't have to pay for the registration.
Alex,
This affects Vector, not just VectorCollection. How do I add the registrations to the initializer for Vector?
Mike
Re: RFC - additional registerClassAlias
Posted by Omar Gonzalez <om...@gmail.com>.
On Thu, Apr 5, 2012 at 2:04 PM, Omar Gonzalez <om...@gmail.com>wrote:
>
>
> On Thu, Apr 5, 2012 at 2:00 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>>
>> On 4/5/12 1:55 PM, "Michael A. Labriola" <la...@digitalprimates.net>
>> wrote:
>>
>> > What would everyone
>> > think about further modifying the compiler to add registrations for the
>> basic
>> > types in the startup of Flex apps?
>> I would put the additional registration calls in the class initializer for
>> VectorCollection. If you aren't using it, you shouldn't have to pay for
>> the
>> registration.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
> This would be a great change. To take this line of thinking further
> though, perhaps we shouldn't make people pay for the registration just for
> using VectorCollection either, or just Vector. Maybe the
> registerClassAlias() calls should go in ByteArray.readObject()?
>
> -omar
>
Nevermind, just realized we can't change that code. :)
-omar
Re: RFC - additional registerClassAlias
Posted by Omar Gonzalez <om...@gmail.com>.
On Thu, Apr 5, 2012 at 2:00 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 4/5/12 1:55 PM, "Michael A. Labriola" <la...@digitalprimates.net>
> wrote:
>
> > What would everyone
> > think about further modifying the compiler to add registrations for the
> basic
> > types in the startup of Flex apps?
> I would put the additional registration calls in the class initializer for
> VectorCollection. If you aren't using it, you shouldn't have to pay for
> the
> registration.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
This would be a great change. To take this line of thinking further though,
perhaps we shouldn't make people pay for the registration just for using
VectorCollection either, or just Vector. Maybe the registerClassAlias()
calls should go in ByteArray.readObject()?
-omar
Re: RFC - additional registerClassAlias
Posted by Alex Harui <ah...@adobe.com>.
On 4/5/12 1:55 PM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
> What would everyone
> think about further modifying the compiler to add registrations for the basic
> types in the startup of Flex apps?
I would put the additional registration calls in the class initializer for
VectorCollection. If you aren't using it, you shouldn't have to pay for the
registration.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui