You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reading and writing functions provided by files and the IDuplex interface are very bare bones, the user is manually required to pass in buffers, positions, and lengths and there are no out of the box convenience functions for existing haxe standard library types. Not only is this a big step backwards from the existing synchronous stream api but I'd imagine one of the first things a user is going to do is write wrapper functions for strings, int, floats, etc.
The problem with this is that you then have loads of what is essentially the same function floating around in every project implemented to varying degrees of quality. This is probably a good indicator that such functions should be provided out of the box or at the very least in a haxe foundation haxelib (a la format).
Ideally we'd have functions mirroring the existing synchronous stream api.
int8
int16
int32
int64
single
float
string
line
and maybe an extra function for ArrayBufferView. My initial thoughts of this were to have a series of static extension functions which would have a generic haxe implementation handling the buffers for you, targets could then shadow a custom implementation to allow more optimised implementations.
I was thinking in C# terms with this as thats what they do there, the problem with this is that there's very little custom implementation a target could do as all they have to work with is the generic interface and not a concrete implementation. C# is able to get away with this as they have lots of fancy memory and reference related types (Span, Memory, etc, etc) which haxe doesn't have the luxury of.
Apprentice-alchemist had the suggestion of buffered readers and writers.
It may be better to implement some kind of BufferedReader on top of IReadable, to avoid reading/writing a lot of very small chunks. Same for writing.
This would also be a good addition for many cases but I don't think it really solves a situation where someone just wants the convenience of immediately writing something like a string to a writable, as assumably with a buffered writer they'd need to flush it to ensure its sent straight away.
The synchronous stream API also provides an endian-ness toggle, is endian-ness also something we want to support? If so is a toggle the right approach or would having big and little endian variants of all these functions be better?
The text was updated successfully, but these errors were encountered:
The reading and writing functions provided by files and the
IDuplex
interface are very bare bones, the user is manually required to pass in buffers, positions, and lengths and there are no out of the box convenience functions for existing haxe standard library types. Not only is this a big step backwards from the existing synchronous stream api but I'd imagine one of the first things a user is going to do is write wrapper functions for strings, int, floats, etc.The problem with this is that you then have loads of what is essentially the same function floating around in every project implemented to varying degrees of quality. This is probably a good indicator that such functions should be provided out of the box or at the very least in a haxe foundation haxelib (a la format).
Ideally we'd have functions mirroring the existing synchronous stream api.
and maybe an extra function for
ArrayBufferView
. My initial thoughts of this were to have a series of static extension functions which would have a generic haxe implementation handling the buffers for you, targets could then shadow a custom implementation to allow more optimised implementations.I was thinking in C# terms with this as thats what they do there, the problem with this is that there's very little custom implementation a target could do as all they have to work with is the generic interface and not a concrete implementation. C# is able to get away with this as they have lots of fancy memory and reference related types (Span, Memory, etc, etc) which haxe doesn't have the luxury of.
Apprentice-alchemist had the suggestion of buffered readers and writers.
This would also be a good addition for many cases but I don't think it really solves a situation where someone just wants the convenience of immediately writing something like a string to a writable, as assumably with a buffered writer they'd need to flush it to ensure its sent straight away.
The synchronous stream API also provides an endian-ness toggle, is endian-ness also something we want to support? If so is a toggle the right approach or would having big and little endian variants of all these functions be better?
The text was updated successfully, but these errors were encountered: