Deprecate binstring?

[JP Richardson]

I can't see a good reason for binstring anymore. In most cases Buffer will handle all of our needs. For example a CryptoCoin API could always accept Buffers, Uint8Array, or Arrays.

//hex <=> buffer

var buf = new Buffer('FF33BBCC', 'hex');

buf.toString('hex');

//string <=> buffer

var buf = new Buffer('hello world', 'utf8');

buf.toString('utf8');

//array <=> buffer

var buf = new Buffer([0xff, 0x33, 0xbb, 0xcc]);

var arr = [].slice.call(buf);

//uint8array <=> buffer

var ua = new Uint8Array();

var buf = new Buffer(ua);

var newUa = new Uint8Array([].slice.call(buf));

I can't see a reason to keep binstring around in our modules, I use to love it... but the power of Buffers just clicked this week! Haha. Thoughts?

[Brooks Boyd]

The only use I see for it is the polymorphism; if you intend to create several modules that all accept multiple types of inputs (string, buffer, array, etc), you'll have the same sort of decision tree at the beginning of every function (if (Buffer.isBuffer(input))... if (Array.isArray(input))... etc.) to get it in a consistent format (Buffer). If the logic of the decision tree turns out to be flawed, it would have to be changed in all the submodules, while if there's one central utility class (binstring), it would only have to change there, and everything else uses it as a sanitization step.

--
You received this message because you are subscribed to the Google Groups "Bitcoin Hackers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to BitcoinHacker...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JP Richardson]

I think we should axe allowing of strings. Let's force people to put it into a buffer. Maybe not allow arrays or uint8arrays either and just go buffers all of the way? That dramatically simplifies things. We can then publish a short guide or wiki page with the above conversions.

--
Follow me on Twitter: http://twitter.com/jprichardson

[JP Richardson]

The reason I thought that we should axe strings is that there's two much ambiguity. I guess with Arrays or Uint8Arrays it feels like there's not as much or hardly any. I do think that APIs should be flexible in what they allow to be passed in but strict on what they pass out.

So the logic maybe like this:

function doSomething(input) {

  if (Array.isArray(input) || input intanceof Uint8Array)

    input = new Buffer(input);

  if (!Buffer.isBuffer(input)) throw Error("Only Array, Uint8Array, or Buffer supported");

  //logic that operates on buffers

}

That's pretty simply... thoughts?

[JP Richardson]

Arrrg... sorry for the spam, "too" and not "two" :p, what I mean by ambiguity with strings is that... is it a hex string, utf8 string, binary string, ascii string? That's why I thought we should prevent string inputs. Buffer takes care of all of those.

[Brooks Boyd]

Pretty simple from a logic-perspective, but in terms of DRY, you'll have those same three lines at the top of all your "doSomething" methods (every endpoint of the API). I guess I'd remove the first two line and just leave the "if it's not a buffer, throw an error" line as all the validation needed.