You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Greg Dove <gr...@gmail.com> on 2019/02/21 05:20:56 UTC
Heads-up on coming updates to reflection and AMF
Just a fyi about what I am working on....
I am currently working on AMFBinaryData updates to support:
IExternalizable
dynamic class instances
I expect to also support IDynamicPropertyWriter
And refactoring the AMFBinaryData class to be a subclass of BinaryData
(this part is done) and have an api that mirrors the IDataInput/IDataOutput
in flash.
IDataInput and IDataOutput extend the IBinaryDataInput and
IBinaryDataOutput counterparts.
The only inconsistencies at this point for those ByteArraylike interfaces
will be the missing implementation of multibyte string support in
javascript and support for AMF0. I think both of these are low priority.
But maybe they could be addressed in the future if there is need.
There is one 'breaking' change that was required in BinaryData with these
changes.
I had to change the writeBytes/readBytes method signatures.
The original method signature is still available but will become
writeBinaryData/readBinaryData
Aside from the addition of the one extra method here, the changes to
BinaryData are very 'light'
I will check the rest of the framework and make those changes if they are
necessary anywhere. But this would be a simple search and replace fix for
code that relies on the current implementation for anything outside the
framework.
This change is to permit the writeBytes/readBytes methods to work with the
native bytes array classes (so: ByteArray in flash and ArrayBuffer in js,
and that means that the interface remains compatible with the original
flash interface on swf)
Along with these updates, the AMFNetConnection class will be updated to use
the new AMFBinaryData api.
The main part of the above is basically already done locally, but I am
still working on the first two parts. I've kept AMFBinaryData in the
network lib for now, but I think it probably belongs in core, and just
AMFNetConnection could use it in Network lib... something maybe to consider
for later.
So the cloning support via AMFBinaryData will become pretty much the same
as flash ByteArray:
myamfData.writeObject(myRoyalObject);
myamfData.position=0;
var copy:MyRoyaleObject = myamfData.readObject() as MyRoyaleObject;
For the reflection updates, they are corequisite for some of the AMF
updates.
There is a fix for some issues that were introduced a few months back that
broke the lazy evaulation of the getters in TypeDefinition.
There's also a fix for another error exposed by the recent numeric coercion
updates that Josh added to the compiler (which is great).
There will be new reflection utility methods to detect if an object is
dynamic and to get its dynamic fields (separate to sealed properties).
These can probably be reused in some of the mx code. Some of these may need
tuning and improvements over time.
The UnitTests manual test project will become functional again, with new
tests for some of the new functionality/classes. (I am using it to test
between swf and js as I work on things).
Anyway, I hope to have changes in the next few days. Thought I would let
you know in advance...
Re: Heads-up on coming updates to reflection and AMF
Posted by Carlos Rovira <ca...@apache.org>.
Yeah, I think so, but I think that's no problem since we want in this part
maximum compatibility so people could use royale with the server they use
for flex with almost not changes (just use ArrayCollection if they use MX
or use ArrayList if they use normal Royale UI APIs)
El jue., 21 feb. 2019 a las 18:45, Greg Dove (<gr...@gmail.com>)
escribió:
> Sounds good, Carlos.
>
> Actually as another implication...
> This does mean that I am also adding IExternalizable to
>
> org.apache.royale.collections.ArrayList
>
> and obviously uncommenting/adding to
> mx.collections.AC
> mx.collections.AL
>
> I don't think there is any 'PAYG' way to do that which would be compatible
> across targets, I just need to add this.
>
> But I do think the same IExternalizable interface with IDataInput and
> IDataOutput could be used for different serialization formats in the
> future...
>
>
>
>
>
> On Fri, Feb 22, 2019 at 6:09 AM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi Greg,
> >
> > that's great. In that way I can test about our app as a first step, then
> if
> > all goes ok, I can try a second time turning on small messages to try
> > IExternalizable. Finally I can as well enable compression :)
> >
> > El jue., 21 feb. 2019 a las 17:54, Greg Dove (<gr...@gmail.com>)
> > escribió:
> >
> > > Hi Carlos,
> > >
> > > Thanks for your comments. Sure, I have things set up in a local
> branch, I
> > > was just hoping to get feedback as to whether I needed to use that
> > remotely
> > > or not.
> > >
> > > So I will do that.
> > >
> > >
> > >
> > > On Thu, Feb 21, 2019 at 10:13 PM Carlos Rovira <
> carlosrovira@apache.org>
> > > wrote:
> > >
> > > > Hi Greg,
> > > >
> > > > that sounds to me like an amazing work. Thanks for working on this.
> > > >
> > > > I think the best way to integrate this should be creating a branch so
> > > Harbs
> > > > and others could adapt the other code to the new API changes, and
> > commit
> > > to
> > > > that branch that fixes (if there are located in our repo) so all is
> > > working
> > > > when merged. Or all could test our code against those changes and try
> > to
> > > > adapt what we see in our code and report if we find any problem that
> > > should
> > > > be taken into account before merge.
> > > >
> > > > Don't know the uses behind that, but seems that knowing how we should
> > > > change the existing code should make us adapt to the new changes fast
> > and
> > > > easily.
> > > >
> > > > About reflection, I tried some months ago to do some work on that and
> > as
> > > > you said, I found some parts was not working. So great to see you
> fixed
> > > > that as well :)
> > > >
> > > > I think getting APIs more close to the original flash but all in a
> > Royale
> > > > API would be good for all since we'll get other step close to ease
> > > > migrations.
> > > >
> > > > Thanks and can't wait to see that code! :)
> > > >
> > > >
> > > >
> > > > El jue., 21 feb. 2019 a las 9:15, Harbs (<ha...@gmail.com>)
> > > > escribió:
> > > >
> > > > > What did you change? I’m using these methods, so it’s significant
> to
> > > me.
> > > > >
> > > > > > On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com>
> > wrote:
> > > > > >
> > > > > > I had to change the writeBytes/readBytes method signatures.
> > > > > > The original method signature is still available but will become
> > > > > > writeBinaryData/readBinaryData
> > > > >
> > > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Heads-up on coming updates to reflection and AMF
Posted by Greg Dove <gr...@gmail.com>.
Sounds good, Carlos.
Actually as another implication...
This does mean that I am also adding IExternalizable to
org.apache.royale.collections.ArrayList
and obviously uncommenting/adding to
mx.collections.AC
mx.collections.AL
I don't think there is any 'PAYG' way to do that which would be compatible
across targets, I just need to add this.
But I do think the same IExternalizable interface with IDataInput and
IDataOutput could be used for different serialization formats in the
future...
On Fri, Feb 22, 2019 at 6:09 AM Carlos Rovira <ca...@apache.org>
wrote:
> Hi Greg,
>
> that's great. In that way I can test about our app as a first step, then if
> all goes ok, I can try a second time turning on small messages to try
> IExternalizable. Finally I can as well enable compression :)
>
> El jue., 21 feb. 2019 a las 17:54, Greg Dove (<gr...@gmail.com>)
> escribió:
>
> > Hi Carlos,
> >
> > Thanks for your comments. Sure, I have things set up in a local branch, I
> > was just hoping to get feedback as to whether I needed to use that
> remotely
> > or not.
> >
> > So I will do that.
> >
> >
> >
> > On Thu, Feb 21, 2019 at 10:13 PM Carlos Rovira <ca...@apache.org>
> > wrote:
> >
> > > Hi Greg,
> > >
> > > that sounds to me like an amazing work. Thanks for working on this.
> > >
> > > I think the best way to integrate this should be creating a branch so
> > Harbs
> > > and others could adapt the other code to the new API changes, and
> commit
> > to
> > > that branch that fixes (if there are located in our repo) so all is
> > working
> > > when merged. Or all could test our code against those changes and try
> to
> > > adapt what we see in our code and report if we find any problem that
> > should
> > > be taken into account before merge.
> > >
> > > Don't know the uses behind that, but seems that knowing how we should
> > > change the existing code should make us adapt to the new changes fast
> and
> > > easily.
> > >
> > > About reflection, I tried some months ago to do some work on that and
> as
> > > you said, I found some parts was not working. So great to see you fixed
> > > that as well :)
> > >
> > > I think getting APIs more close to the original flash but all in a
> Royale
> > > API would be good for all since we'll get other step close to ease
> > > migrations.
> > >
> > > Thanks and can't wait to see that code! :)
> > >
> > >
> > >
> > > El jue., 21 feb. 2019 a las 9:15, Harbs (<ha...@gmail.com>)
> > > escribió:
> > >
> > > > What did you change? I’m using these methods, so it’s significant to
> > me.
> > > >
> > > > > On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com>
> wrote:
> > > > >
> > > > > I had to change the writeBytes/readBytes method signatures.
> > > > > The original method signature is still available but will become
> > > > > writeBinaryData/readBinaryData
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Heads-up on coming updates to reflection and AMF
Posted by Carlos Rovira <ca...@apache.org>.
Hi Greg,
that's great. In that way I can test about our app as a first step, then if
all goes ok, I can try a second time turning on small messages to try
IExternalizable. Finally I can as well enable compression :)
El jue., 21 feb. 2019 a las 17:54, Greg Dove (<gr...@gmail.com>)
escribió:
> Hi Carlos,
>
> Thanks for your comments. Sure, I have things set up in a local branch, I
> was just hoping to get feedback as to whether I needed to use that remotely
> or not.
>
> So I will do that.
>
>
>
> On Thu, Feb 21, 2019 at 10:13 PM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi Greg,
> >
> > that sounds to me like an amazing work. Thanks for working on this.
> >
> > I think the best way to integrate this should be creating a branch so
> Harbs
> > and others could adapt the other code to the new API changes, and commit
> to
> > that branch that fixes (if there are located in our repo) so all is
> working
> > when merged. Or all could test our code against those changes and try to
> > adapt what we see in our code and report if we find any problem that
> should
> > be taken into account before merge.
> >
> > Don't know the uses behind that, but seems that knowing how we should
> > change the existing code should make us adapt to the new changes fast and
> > easily.
> >
> > About reflection, I tried some months ago to do some work on that and as
> > you said, I found some parts was not working. So great to see you fixed
> > that as well :)
> >
> > I think getting APIs more close to the original flash but all in a Royale
> > API would be good for all since we'll get other step close to ease
> > migrations.
> >
> > Thanks and can't wait to see that code! :)
> >
> >
> >
> > El jue., 21 feb. 2019 a las 9:15, Harbs (<ha...@gmail.com>)
> > escribió:
> >
> > > What did you change? I’m using these methods, so it’s significant to
> me.
> > >
> > > > On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com> wrote:
> > > >
> > > > I had to change the writeBytes/readBytes method signatures.
> > > > The original method signature is still available but will become
> > > > writeBinaryData/readBinaryData
> > >
> > >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Heads-up on coming updates to reflection and AMF
Posted by Greg Dove <gr...@gmail.com>.
Hi Carlos,
Thanks for your comments. Sure, I have things set up in a local branch, I
was just hoping to get feedback as to whether I needed to use that remotely
or not.
So I will do that.
On Thu, Feb 21, 2019 at 10:13 PM Carlos Rovira <ca...@apache.org>
wrote:
> Hi Greg,
>
> that sounds to me like an amazing work. Thanks for working on this.
>
> I think the best way to integrate this should be creating a branch so Harbs
> and others could adapt the other code to the new API changes, and commit to
> that branch that fixes (if there are located in our repo) so all is working
> when merged. Or all could test our code against those changes and try to
> adapt what we see in our code and report if we find any problem that should
> be taken into account before merge.
>
> Don't know the uses behind that, but seems that knowing how we should
> change the existing code should make us adapt to the new changes fast and
> easily.
>
> About reflection, I tried some months ago to do some work on that and as
> you said, I found some parts was not working. So great to see you fixed
> that as well :)
>
> I think getting APIs more close to the original flash but all in a Royale
> API would be good for all since we'll get other step close to ease
> migrations.
>
> Thanks and can't wait to see that code! :)
>
>
>
> El jue., 21 feb. 2019 a las 9:15, Harbs (<ha...@gmail.com>)
> escribió:
>
> > What did you change? I’m using these methods, so it’s significant to me.
> >
> > > On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com> wrote:
> > >
> > > I had to change the writeBytes/readBytes method signatures.
> > > The original method signature is still available but will become
> > > writeBinaryData/readBinaryData
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Heads-up on coming updates to reflection and AMF
Posted by Carlos Rovira <ca...@apache.org>.
Hi Greg,
that sounds to me like an amazing work. Thanks for working on this.
I think the best way to integrate this should be creating a branch so Harbs
and others could adapt the other code to the new API changes, and commit to
that branch that fixes (if there are located in our repo) so all is working
when merged. Or all could test our code against those changes and try to
adapt what we see in our code and report if we find any problem that should
be taken into account before merge.
Don't know the uses behind that, but seems that knowing how we should
change the existing code should make us adapt to the new changes fast and
easily.
About reflection, I tried some months ago to do some work on that and as
you said, I found some parts was not working. So great to see you fixed
that as well :)
I think getting APIs more close to the original flash but all in a Royale
API would be good for all since we'll get other step close to ease
migrations.
Thanks and can't wait to see that code! :)
El jue., 21 feb. 2019 a las 9:15, Harbs (<ha...@gmail.com>) escribió:
> What did you change? I’m using these methods, so it’s significant to me.
>
> > On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com> wrote:
> >
> > I had to change the writeBytes/readBytes method signatures.
> > The original method signature is still available but will become
> > writeBinaryData/readBinaryData
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Heads-up on coming updates to reflection and AMF
Posted by Greg Dove <gr...@gmail.com>.
Thanks for the ideas Harbs. I'll suggest that it will be easier to discuss
these after I push to a remote branch and you can take a look. My aim was
to keep the writeData ('writeBinaryData') and readData ('readBinaryData')
signatures the same as the originals (original readBytes/writeBytes) for
now. My interpretation of your last comments is that you are suggesting
possible changes to those original method signatures.
I think that could be done on the write side, but the reading side would
not be the same without reference to the target BinaryData, because it
needs access to the target BinaryData to support 'growing' its ArrayBuffer
if needed (in which case it would be a different ArrayBuffer instance).
Anyway, I will put this all in a branch with the compiler changes and as-js
changes aligned so you can check things first. It may still be a day or two
before I get there.
On Fri, Feb 22, 2019 at 6:27 AM Harbs <ha...@gmail.com> wrote:
> Maybe the type of “data” should be platform specific?
>
> Then you could use: bd2.writeData(bd1.data);
>
> > On Feb 21, 2019, at 7:18 PM, Greg Dove <gr...@gmail.com> wrote:
> >
> > The main thought was for things like xhr.response which is ArrayBuffer
> and
> > can be used directly.
> > That could be changed if it was preferred. I kept it the same as it was
> the
> > native 'bytearray' implementation for the target platform and that seemed
> > to correspond more to ArrayBuffer than Uint8Array. But those two are very
> > easily interchanged I think - ArrayBuffer just seemed the more base level
> > implementation.
> >
> > anyway, as I have it now, writeBinaryData is basically doing the same
> thing:
> >
> > COMPILE::JS
> > {
> > writeBytes(bytes.ba as ArrayBuffer)
> > }
> >
> > with @royaleignorecoercion ArrayBuffer
> >
> > More caution is obviously needed for using the readBytes method because
> > these things in js are fixed length compared to ByteArray which grows as
> > needed.
> >
> >
> > On Fri, Feb 22, 2019 at 6:03 AM Harbs <ha...@gmail.com> wrote:
> >
> >> What’s the reason you are using ArrayBuffer instead of Uint8Array on the
> >> JS side?
> >>
> >> If you’d use Uint8Array instead, the method could be used like so:
> >>
> >> bd2.writeData(bd1.array);
> >>
> >>
> >>> On Feb 21, 2019, at 6:40 PM, Greg Dove <gr...@gmail.com> wrote:
> >>>
> >>> Hi Harbs,
> >>>
> >>> Part of the reason for posting this was to surface any concerns early.
> >>> This is my fault because when I added these methods a few years back I
> >>> thought it seemed ok to use BinaryData as the 'bytes' argument type in
> >> them
> >>> at the time. But the issue there is that it breaks compatibility with
> swf
> >>> interfaces for IExternalizable, because that becomes incompatible for
> >>> readBytes/writeBytes in the IDataInput/IDataOutput interfaces.
> >>> I guess it could be avoidable in other ways, but it seems better to go
> >> for
> >>> the consistency and provide the writeBytes/readBytes methods as the
> >> native
> >>> platform variants.
> >>>
> >>> The change however is quite trivial:
> >>>
> >>> what was
> >>> function writeBytes(bytes:BinaryData, offset:uint = 0, length:uint =
> >> 0):void
> >>>
> >>> will become
> >>>
> >>> COMPILE::SWF
> >>> public function writeBytes(bytes:ByteArray, offset:uint = 0,
> length:uint
> >> =
> >>> 0):void
> >>>
> >>> and
> >>> COMPILE::JS
> >>> public function writeBytes(bytes:ArrayBuffer, offset:uint = 0,
> >> length:uint
> >>> = 0):void
> >>>
> >>> and the original method signature will remain available as:
> >>> public function writeBinaryData(bytes:BinaryData, offset:uint = 0,
> >>> length:uint = 0):void
> >>>
> >>> Likewise for the corresponding read methods. And although the code has
> >>> changed slightly, it works as before.
> >>>
> >>> So it is a simple search and replace in files
> >>>
> >>>
> >>> On Thu, Feb 21, 2019 at 9:15 PM Harbs <ha...@gmail.com> wrote:
> >>>
> >>>> What did you change? I’m using these methods, so it’s significant to
> me.
> >>>>
> >>>>> On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com> wrote:
> >>>>>
> >>>>> I had to change the writeBytes/readBytes method signatures.
> >>>>> The original method signature is still available but will become
> >>>>> writeBinaryData/readBinaryData
> >>>>
> >>>>
> >>
> >>
>
>
Re: Heads-up on coming updates to reflection and AMF
Posted by Harbs <ha...@gmail.com>.
Maybe the type of “data” should be platform specific?
Then you could use: bd2.writeData(bd1.data);
> On Feb 21, 2019, at 7:18 PM, Greg Dove <gr...@gmail.com> wrote:
>
> The main thought was for things like xhr.response which is ArrayBuffer and
> can be used directly.
> That could be changed if it was preferred. I kept it the same as it was the
> native 'bytearray' implementation for the target platform and that seemed
> to correspond more to ArrayBuffer than Uint8Array. But those two are very
> easily interchanged I think - ArrayBuffer just seemed the more base level
> implementation.
>
> anyway, as I have it now, writeBinaryData is basically doing the same thing:
>
> COMPILE::JS
> {
> writeBytes(bytes.ba as ArrayBuffer)
> }
>
> with @royaleignorecoercion ArrayBuffer
>
> More caution is obviously needed for using the readBytes method because
> these things in js are fixed length compared to ByteArray which grows as
> needed.
>
>
> On Fri, Feb 22, 2019 at 6:03 AM Harbs <ha...@gmail.com> wrote:
>
>> What’s the reason you are using ArrayBuffer instead of Uint8Array on the
>> JS side?
>>
>> If you’d use Uint8Array instead, the method could be used like so:
>>
>> bd2.writeData(bd1.array);
>>
>>
>>> On Feb 21, 2019, at 6:40 PM, Greg Dove <gr...@gmail.com> wrote:
>>>
>>> Hi Harbs,
>>>
>>> Part of the reason for posting this was to surface any concerns early.
>>> This is my fault because when I added these methods a few years back I
>>> thought it seemed ok to use BinaryData as the 'bytes' argument type in
>> them
>>> at the time. But the issue there is that it breaks compatibility with swf
>>> interfaces for IExternalizable, because that becomes incompatible for
>>> readBytes/writeBytes in the IDataInput/IDataOutput interfaces.
>>> I guess it could be avoidable in other ways, but it seems better to go
>> for
>>> the consistency and provide the writeBytes/readBytes methods as the
>> native
>>> platform variants.
>>>
>>> The change however is quite trivial:
>>>
>>> what was
>>> function writeBytes(bytes:BinaryData, offset:uint = 0, length:uint =
>> 0):void
>>>
>>> will become
>>>
>>> COMPILE::SWF
>>> public function writeBytes(bytes:ByteArray, offset:uint = 0, length:uint
>> =
>>> 0):void
>>>
>>> and
>>> COMPILE::JS
>>> public function writeBytes(bytes:ArrayBuffer, offset:uint = 0,
>> length:uint
>>> = 0):void
>>>
>>> and the original method signature will remain available as:
>>> public function writeBinaryData(bytes:BinaryData, offset:uint = 0,
>>> length:uint = 0):void
>>>
>>> Likewise for the corresponding read methods. And although the code has
>>> changed slightly, it works as before.
>>>
>>> So it is a simple search and replace in files
>>>
>>>
>>> On Thu, Feb 21, 2019 at 9:15 PM Harbs <ha...@gmail.com> wrote:
>>>
>>>> What did you change? I’m using these methods, so it’s significant to me.
>>>>
>>>>> On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com> wrote:
>>>>>
>>>>> I had to change the writeBytes/readBytes method signatures.
>>>>> The original method signature is still available but will become
>>>>> writeBinaryData/readBinaryData
>>>>
>>>>
>>
>>
Re: Heads-up on coming updates to reflection and AMF
Posted by Greg Dove <gr...@gmail.com>.
The main thought was for things like xhr.response which is ArrayBuffer and
can be used directly.
That could be changed if it was preferred. I kept it the same as it was the
native 'bytearray' implementation for the target platform and that seemed
to correspond more to ArrayBuffer than Uint8Array. But those two are very
easily interchanged I think - ArrayBuffer just seemed the more base level
implementation.
anyway, as I have it now, writeBinaryData is basically doing the same thing:
COMPILE::JS
{
writeBytes(bytes.ba as ArrayBuffer)
}
with @royaleignorecoercion ArrayBuffer
More caution is obviously needed for using the readBytes method because
these things in js are fixed length compared to ByteArray which grows as
needed.
On Fri, Feb 22, 2019 at 6:03 AM Harbs <ha...@gmail.com> wrote:
> What’s the reason you are using ArrayBuffer instead of Uint8Array on the
> JS side?
>
> If you’d use Uint8Array instead, the method could be used like so:
>
> bd2.writeData(bd1.array);
>
>
> > On Feb 21, 2019, at 6:40 PM, Greg Dove <gr...@gmail.com> wrote:
> >
> > Hi Harbs,
> >
> > Part of the reason for posting this was to surface any concerns early.
> > This is my fault because when I added these methods a few years back I
> > thought it seemed ok to use BinaryData as the 'bytes' argument type in
> them
> > at the time. But the issue there is that it breaks compatibility with swf
> > interfaces for IExternalizable, because that becomes incompatible for
> > readBytes/writeBytes in the IDataInput/IDataOutput interfaces.
> > I guess it could be avoidable in other ways, but it seems better to go
> for
> > the consistency and provide the writeBytes/readBytes methods as the
> native
> > platform variants.
> >
> > The change however is quite trivial:
> >
> > what was
> > function writeBytes(bytes:BinaryData, offset:uint = 0, length:uint =
> 0):void
> >
> > will become
> >
> > COMPILE::SWF
> > public function writeBytes(bytes:ByteArray, offset:uint = 0, length:uint
> =
> > 0):void
> >
> > and
> > COMPILE::JS
> > public function writeBytes(bytes:ArrayBuffer, offset:uint = 0,
> length:uint
> > = 0):void
> >
> > and the original method signature will remain available as:
> > public function writeBinaryData(bytes:BinaryData, offset:uint = 0,
> > length:uint = 0):void
> >
> > Likewise for the corresponding read methods. And although the code has
> > changed slightly, it works as before.
> >
> > So it is a simple search and replace in files
> >
> >
> > On Thu, Feb 21, 2019 at 9:15 PM Harbs <ha...@gmail.com> wrote:
> >
> >> What did you change? I’m using these methods, so it’s significant to me.
> >>
> >>> On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com> wrote:
> >>>
> >>> I had to change the writeBytes/readBytes method signatures.
> >>> The original method signature is still available but will become
> >>> writeBinaryData/readBinaryData
> >>
> >>
>
>
Re: Heads-up on coming updates to reflection and AMF
Posted by Harbs <ha...@gmail.com>.
What’s the reason you are using ArrayBuffer instead of Uint8Array on the JS side?
If you’d use Uint8Array instead, the method could be used like so:
bd2.writeData(bd1.array);
> On Feb 21, 2019, at 6:40 PM, Greg Dove <gr...@gmail.com> wrote:
>
> Hi Harbs,
>
> Part of the reason for posting this was to surface any concerns early.
> This is my fault because when I added these methods a few years back I
> thought it seemed ok to use BinaryData as the 'bytes' argument type in them
> at the time. But the issue there is that it breaks compatibility with swf
> interfaces for IExternalizable, because that becomes incompatible for
> readBytes/writeBytes in the IDataInput/IDataOutput interfaces.
> I guess it could be avoidable in other ways, but it seems better to go for
> the consistency and provide the writeBytes/readBytes methods as the native
> platform variants.
>
> The change however is quite trivial:
>
> what was
> function writeBytes(bytes:BinaryData, offset:uint = 0, length:uint = 0):void
>
> will become
>
> COMPILE::SWF
> public function writeBytes(bytes:ByteArray, offset:uint = 0, length:uint =
> 0):void
>
> and
> COMPILE::JS
> public function writeBytes(bytes:ArrayBuffer, offset:uint = 0, length:uint
> = 0):void
>
> and the original method signature will remain available as:
> public function writeBinaryData(bytes:BinaryData, offset:uint = 0,
> length:uint = 0):void
>
> Likewise for the corresponding read methods. And although the code has
> changed slightly, it works as before.
>
> So it is a simple search and replace in files
>
>
> On Thu, Feb 21, 2019 at 9:15 PM Harbs <ha...@gmail.com> wrote:
>
>> What did you change? I’m using these methods, so it’s significant to me.
>>
>>> On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com> wrote:
>>>
>>> I had to change the writeBytes/readBytes method signatures.
>>> The original method signature is still available but will become
>>> writeBinaryData/readBinaryData
>>
>>
Re: Heads-up on coming updates to reflection and AMF
Posted by Greg Dove <gr...@gmail.com>.
Hi Harbs,
Part of the reason for posting this was to surface any concerns early.
This is my fault because when I added these methods a few years back I
thought it seemed ok to use BinaryData as the 'bytes' argument type in them
at the time. But the issue there is that it breaks compatibility with swf
interfaces for IExternalizable, because that becomes incompatible for
readBytes/writeBytes in the IDataInput/IDataOutput interfaces.
I guess it could be avoidable in other ways, but it seems better to go for
the consistency and provide the writeBytes/readBytes methods as the native
platform variants.
The change however is quite trivial:
what was
function writeBytes(bytes:BinaryData, offset:uint = 0, length:uint = 0):void
will become
COMPILE::SWF
public function writeBytes(bytes:ByteArray, offset:uint = 0, length:uint =
0):void
and
COMPILE::JS
public function writeBytes(bytes:ArrayBuffer, offset:uint = 0, length:uint
= 0):void
and the original method signature will remain available as:
public function writeBinaryData(bytes:BinaryData, offset:uint = 0,
length:uint = 0):void
Likewise for the corresponding read methods. And although the code has
changed slightly, it works as before.
So it is a simple search and replace in files
On Thu, Feb 21, 2019 at 9:15 PM Harbs <ha...@gmail.com> wrote:
> What did you change? I’m using these methods, so it’s significant to me.
>
> > On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com> wrote:
> >
> > I had to change the writeBytes/readBytes method signatures.
> > The original method signature is still available but will become
> > writeBinaryData/readBinaryData
>
>
Re: Heads-up on coming updates to reflection and AMF
Posted by Harbs <ha...@gmail.com>.
What did you change? I’m using these methods, so it’s significant to me.
> On Feb 21, 2019, at 7:20 AM, Greg Dove <gr...@gmail.com> wrote:
>
> I had to change the writeBytes/readBytes method signatures.
> The original method signature is still available but will become
> writeBinaryData/readBinaryData