Or are you referring to Buffer which StringBuffer and BlobBuffer inherit
from?
That exists for multiple reasons:
- So you can prototype abstract methods onto buffers. (At that, .insert,
.append, etc... could actually be built using pure-js and prototyped on
to Buffer)
- So that you can construct buffers without worrying about what type
they are (abstract algorithms like; Construct buffer, read data, append
data to buffer, continue until data source is empty, convert buffer to
non-mutable type, return that data.) using simple techniques like:
var buf = new Buffer(seq); // Takes either a String or a Blob and
creates either a StringBuffer or a BlobBuffer.
var buf = new Buffer(stream.contentConstructor); // Takes the
contentConstructor from a stream or whatever, and creates either a
StringBuffer or a BlobBuffer that matches.
We need both low level APIs on which to build high level APIs and we
need high level APIs to build interoperable applications.
It is a useful exercise, and one that you rightly point out Tom and I
are engaging, to discover what the minimal, cross-engine, cross-os
part of each of CommonJS APIs need be implemented on each engine,
either natively or as adapters. The idea is to provide a minimal low
level API foundation on which to build the application API in pure
JavaScript.
Perhaps the issue is not so much that we have failed to do this, but
that we've not realized that it would be beneficial to codify a
standard for both layers. I believe our reluctance to do this stems
not from our desire to have such layers, but a fear of getting hung up
on implementation details in the process.
Kris Kowal
Buffer itself is trivial anyways, it's not like it's any trouble at all
to implement.
function Buffer(o, l) {
if ( !arguments.length )
return this;
if ( o instanceof String )
return new StringBuffer(o);
if ( o instanceof Blob )
return new BlobBuffer(o);
if ( arguments.length > 1 ) {
if ( o === String )
return new StringBuffer(l);
if ( o === Blob )
return new BlobBuffer(l);
}
if ( o === String )
return new StringBuffer();
if ( o === Blob )
return new BlobBuffer();
}
Buffer.prototype.toSource = function () { return "(new Buffer())"; };
Heck, frankly you don't even need that if( arguments.length > 1 ) block...
So:
- No pain to implement
- When writing abstract code lets you construct buffers without needing
to check types yourself.
- Lets you easily just assign prototype methods onto Buffer.prototype
instead of StringBuffer.prototype and BlobBuffer.prototype separately.
Yank is the easiest one to come to mind (actually, I implement .read()
in the same way).
Yes, I agree to this point.
It's usually the time spent going into nitty-gritty details and
trying different models that make you understand the problem
domain. That will eventually help you make the right choices in
a (maybe smaller and simpler) final design. It's a natural design
process to start out with something seemingly simple, having this
grow into a complex monster while solving different use cases, to
eventually (with the experience gained) being able to cut it down
to something simple and contained again.
That said, the "complex" phase shouldn't go on forever, there
must be limits. Also, if the complex phase is too slow/inactive,
participants seem to forget the killer use cases that made all
the difference a month ago, and everything has to be repeated
over and over again.
Just my 2c.
Best regards
Mike
Yes, I agree to this point.
Hannes Wallnoefer wrote:
> I feel quite different about these things. I think it's really
> important that we take our time to come up with an API that provides
> what developers need while keeping it plain and simple. And that may
> just take some experimentation, including some dead ends.
It's usually the time spent going into nitty-gritty details and
trying different models that make you understand the problem
domain.
> It's worth noting that to truly get to those nitty gritty details requires real apps trying to do real things.FWIW, most of my frustration in this regard boils around the fact that I am trying very hard to build a significant project in CommonJS.
My team has had to veer off into "make up ad-hoc APIs out of FFI" land pretty hard as CommonJS is lagging and overly complicated for simple use cases.
On the other hand, the FFI API we've built is reaching maturity due to this process quite quickly!
I think this approach is a good idea. We have security requirements
on the high level that won't be relevant at these levels, so this will
help separate concerns. It would be neat if all of the "file" module
could be built on binary and lower level, privileged modules that,
while unavailable in a security context, would still serve as the
basis for that functionality.
Kris Kowal