Andrei Alexandrescu napisał: > > I don't see a clear need for the two to be separate. Could they fold > > into popFront(n, m) meaning shiftFront(n); appendToFront(m) ? Nullary > > popFront() discards all and loads any number it pleases. > > I think combining the two into one hurts usability as often you want to > do one without the other.
OK, but if you go this way, what would popFront() do? > > Some users would benefit if they could just pass in a buffer and say > > "fill'er up". > > Correct. That observation applies to unbuffered input as well. Right. > > Contiguous, yes. But I'd rather see front() exposing, say, a circular > > buffer so that appendToFront(n) reallocates only when n> > > buf.length. > > > > I think circularity is an implementation detail that is poor as a > client-side abstraction. I fear efficiency will get abstracted out. Say this is my internal buffer (pipes indicate front() slice): [ooo|oooooo|oo] Now I do appendToFront(3) -- how do you expose the expected front() without moving data? -- Tomek
