Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: add support for setting endian type in the constructor options #38

Open
rluvaton opened this issue Jul 5, 2021 · 1 comment

Comments

@rluvaton
Copy link

rluvaton commented Jul 5, 2021

Great project!

It would be great if we could pass the endian type in the constructor and have a request like writeUint32 that will use the passed endian

@soanvig
Copy link

soanvig commented May 6, 2022

Just saw this browsing the issues from curiosity.
I'm not the library author, but I'll leave a comment.

Don't ask to add bloat and dozens of configuration options to libraries. Let's keep them simple, and do one thing, and do it right.

As I somehow understand the need for that (abstracting away protocol details like endian type) from the responsibility perspective (e.g. by passing prepared and configured with endianess smart buffers to other parts of the code) it can be easily implemented by wrapping SmartBuffer in adapter class that works like that.

If this is your case, just wrap SmartBuffer and you are done.

IMHO it is not this library responsibility to manage endianess in "automated" way - just for the sake that this approach is not generic enough and can be misleading if for some reason BE and LE is mixed in one buffer, which may happen. Instead of one explicit way of doing things you would be having one explicit and one implicit way, which sounds bad.

Well designed library does exactly one thing and allows "extending" it by wrappers. SmartBuffer currently does one thing, does it well, don't change it, don't complicate it's API that will lower it's extensibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants