flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: FlexJS question - ByteArray vs. BinaryData
Date Thu, 14 Jul 2016 14:45:54 GMT

On 7/13/16, 11:33 PM, "Greg Dove" <greg.dove@gmail.com> wrote:

>Harbs and Alex, thanks for your explanations.
>I guess 'drop-in' replacement is quite unrealistic. But I think if could
>closer to the IDataInput/IDataOutput, and given that ByteArray is a common
>utility class in many libraries, particularly for low-level parsing of
>various formats, the closer the better imo.
>In my experience most ByteArray use seems to be mostly sequential reading
>or writing which uses the flash class' read/write methods instead of array
>access. So in terms of migration effort, swapping array access out
>it is used to the method-based getByteAt, setByteAt is not so bad.

When we get around to needing a better ByteArray for the MX/Spark
emulation, I may look into having the compiler handle [] accessors on
ByteArray.  We have it working for Proxy already.

For the Basic set, I would still opt for pay-as-you-go plug-in
capabilities.  You can aggregate those pieces into a big heavy drop-in
replacement of ByteArray, but folks who don't need all of that can only
pay for what they need.

>Harbs, I picked up the recent updates from nightly and there is more there
>than what I had for sure, but more to do I think - perhaps I can help - I
>will try to work on this over the next day or so and share where I get to.
>After using Flex for 8 years I am kinda struggling with my setup for
>FlexJS, and I'm not sure if I can use monkey-patching  for checking the
>additions I have in mind.... which I could do in the past with the regular
>flex sdk.

Standard monkey-patching would work for the SWF version of the code.  We
don't have a similar workflow for the JS version.  Instead, you can
hand-edit the cross-compiled JS output and store it in the
frameworks/js/generated-sources folder.

It would be great to have you push on trying to port your app and
contribute to FlexJS.  A key thing about Apache projects is that there is
no upper management deciding what code gets written next.  You can write
what you need when you need it.

FlexJS won't be a 100% drop-in replacement for Flex, at least not in the
short term.  Its goal is to be less work and risk than porting all the way
to another JS framework, and to save you time maintaining that code going
forward since you can use structured languages and declarative languages
all from a single vendor.  And there is no corporation that owns the
technology that can decide to change directions.  Many of the most popular
JS frameworks have corporate influence.


View raw message