RFC: Compatibility issues with ByteArray about nme HOT 4 CLOSED

1.) If we can implement ArrayAccess for the HTML5 ByteArray, that sounds fine :)

2.) I think that extending Bytes is very pragmatic. Some libraries require an object of type Bytes. Being able to pass an NME ByteArray into these methods directly is very useful. I would break this releationship only as a very last resort, for a very important reason.

To me, it seems like the length should not be writable. The only time I've seen it used in Flash is to set the length to zero, as a hack to free the memory.

3.) This seems like a good improvement, though is "windowBits" the right name to use? At first glance, it seems confusing. Should it be something like "format" instead, with static variables defined on Compress, so you can use "new Compress (50, Compress.ZIP)", or something similar?

We could temporarily include our own copy of the Compress classes within NME, then submit patches to Haxe and Neko. Once Haxe is released with the improvement, we could remove our own copy. We would also remove the Neko version (which would ignore the format type at first) once a new Neko version was released.

from nme.

1. Great. I will try.

2. The problem relying with that ByteArray extends Bytes is that you can't make portable code since flash's ByteArray doesn't extend Bytes nor jeash. (I have encountered problems with that precissely). So, what about a static method inside a class included with NME that converts Bytes <-> ByteArray?
   Also, I'm usually setting the length just after the ByteArray construction in order to generate bytes with the Memory class or using the ArrayAccess interface with all the memory already allocated.
   My main concern is about getting seamlessly portability between platforms, so it works without conditional compilation on each supported platform. That's why I suggested the change.

3. Ok. It seems fine to me :) I will implement it with an "#if cpp" and will include the code in nme, then I will submit patches to hxcpp and nekovm.

I will try to implement 1 and 3 at this point asap.
What do you think about my points on 2? Any ideas/alternatives on that?

Regards.

from nme.

I believe the Haxe Bytes class relates to something fundamental in the way HXCPP is designed, which means that NME ByteArrays can be passed directly into native methods and used as bytes.

Is setting ".length" the only problem?

from nme.

I was thinking a bit more on that. Probably the APIs using Bytes are only available on HXCPP and NEKO, and there is where the ByteArray is extending Bytes. Probably the problems I had were related to APIs that returned a Bytes object and me expecting to use it as a ByteArray. In the end I made a utility class for converting Bytes to ByteArrays and forth and to create ByteArrays with a fixed length. So I won't insist more on that (unless haxe implements an implicit cast operator in the future).

Thanks for your comments!

from nme.