Inconsistent behaviour `new BytesOutput().getBytes().getData()` in standard library

[polygonal]

//swf,cpp:
var output = new haxe.io.BytesOutput();
for (i in 0...256) output.writeInt16(1);

var bytes = output.getBytes();
trace(bytes.length); // 512

var data = bytes.getData();
trace(data.length); // 512;

//js:
var output = new haxe.io.BytesOutput();
for (i in 0...256) output.writeInt16(1);

var bytes = output.getBytes();
trace(bytes.length); // 512

var data = bytes.getData();
trace(data.length); // ERROR: haxe.io.BytesData has no field length

trace(data.byteLength); // 609, should be 512

How to reproduce (Haxe 4.0.2):

• Compile first example with -swf or -cpp
  • both bytes.length and data.length are correct
• Compile second example with -js
  • first problem: length property is not defined
  • second problem: switching to byteLength, it seems the internal buffer is returned instead of the actual written bytes

[Aurel300]

first problem: length property is not defined

Nothing to be done here – haxe.io.BytesData is a type alias that maps to appropriate native types on all targets. On js that happens to be ArrayBuffer, which does not have a length property. haxe.io.BytesData should not be relied upon as target-consistent.

Unsure about the second problem, I assume we over-allocate in BytesOutput so that we don't have to extend the bytes object every time a new byte is added?

[RealyUniqueName]

We can switch BytesData to an abstract with no fields to hide target details. It will allow to avoid confusion like that, but still allow to access native implementation via cast

[ncannasse]

I think we should keep it the way it is now. BytesData is platform specific.

…

On Mon, Nov 18, 2019 at 9:55 AM Aleksandr Kuzmenko ***@***.***> wrote: We can switch BytesData to an abstract with no fields to hide target details. It will allow to avoid confusion like that, but still allow to access native implementation via cast — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8974?email_source=notifications&email_token=AAHZXQA7FSM52AHEALFX33TQUJKBNA5CNFSM4JOLRZBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEJV25Q#issuecomment-554917238>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZXQDGTZMMA3ZU7TUHW43QUJKBNANCNFSM4JOLRZBA> .

[polygonal]

Ok I agree regarding the first issue, but calling getBytes() should return a trimmed version of the buffer, storing only the actual written bytes.

[Geokureli]

PR #12533 was a bust, some takeaways:

It's pretty confusing that haxe.io.BytesBuffer has #if js conditions while js also has its own BytesBuffer implementation.

The size discrepancy is because BytesBuffer.grow increases the size to a multiple of 8 to reduce instantiations. Assuming that js's ArrayBuffer and Uint8Array are faster than using Array, so as to warrant the extra complexity. I don't think there's anything we can do here other than clarify this behavior on js, and avoid confusion between the two BytesBuffers types

Edit: What if we added a length arg to js's Bytes constructor, seeing how other targets have this. This would specifically fix implementations that use the data to create another Bytes instance (this would fix lime's issue, for instance)