I have been working on a cleaner ByteArray class – one that has consistent code between platforms and is closer to the original spec.
Since Haxe 3.2, the core haxe.io.Bytes
type has improved significantly, so we’re moving to a new implementation that centers on it. There’s a decision, though, whether to make ByteArray abstract. There are some pros and cons:
Abstract ByteArray
If openfl.utils.ByteArray
is an abstract then we get array access:
byteArray[0] = 1000;
It also adds some interesting support for casting:
var bytes:Bytes = byteArray;
var arrayBuffer:ArrayBuffer = byteArray;
An abstract type does not exist at runtime, so Std.is (byteArray, ByteArray)
would fail (though Std.is (byteArray, Bytes)
would work on non-Flash platforms), or you could use the IDataInput
or IDataOutput
interface to check it.
Another downside of an abstract, is extended classes. MyClass extends Bytes
would work but MyClass extends ByteArray
would not.
Class ByteArray
Keeping ByteArray a class will be closer to our current behavior. Std.is (byteArray, ByteArray)
would work, as well as MyClass extends ByteArray
, but converting to and from haxe.io.Bytes
will require conditional code depending on the platform. An abstract solves that problem for us. We also lose array access, the best we could do is:
byteArray.set (100, 120);
If we extend haxe.io.Bytes
(which is what we currently do), we cannot set length
. Using byteArray.length = 0;
(similar to Flash) is possible if we use an abstract
(above), or possibly if we have a separate bytes
property internally and do not extend Bytes
, but without abstract
auto-casting, you could not use a ByteArray
as Bytes
directly.
Poll
What do you think?
- (EDIT: option removed)
- I like the benefits of an abstract ByteArray
- I prefer the benefits of a ByteArray class
0 voters