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:
openfl.utils.ByteArray is an abstract then we get array access:
byteArray = 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
IDataOutput interface to check it.
Another downside of an abstract, is extended classes.
MyClass extends Bytes would work but
MyClass extends ByteArray would not.
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
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
What do you think?
- (EDIT: option removed)
- I like the benefits of an abstract ByteArray
- I prefer the benefits of a ByteArray class