buffered input

[spir]

On 02/06/2011 04:11 AM, Andrei Alexandrescu wrote:
> On 2/5/11 5:22 PM, Nick Sabalausky wrote:
>> "Heywood Floyd"<soul8o8 at gmail.com> wrote in message
>> news:mailman.1318.1296941395.4748.digitalmars-d at puremagic.com...
>>>
>>> As in, you've built some library that passes around ranges, but then some
>>> part of it is slow and needs buffered ones. Isn't the point that you can
>>> then swap out your ranges for buffered ones here and there, but continue to
>>> have a functioning library?
>>
>> The problem with that is that in many many cases it forces unnessisary
>> copying. We can get much better performance with this slightly more
>> "hands-on" version. But that said, if the traditional "hands-free automatic
>> buffering" really is all you need, then such a thing [should] be easily to
>> construct out of the Andrei's style of buffered range.
>>
>>
>>> Then follows that popFront() means "discard the first _element_, so that
>>> the element that was second now becomes first." And if we can agree to
>>> that, then shiftFront() is possibly very confusing, and so is
>>> appendToFront(). They sound like they operate on the first element!
>>
>> I completely agree. The names of those functions confused the hell out of me
>> until I read Andrei's descriptions of them. Now I understand what they
>> do...but I still don't understand their names at all.
>
> Better names are always welcome!

If append actually appends into buffer (what I understand as of now), then 
appendToBuf(er). For shiftFront, maybe eatSlice? popFrontSlice would be very 
good (esp as opposed to a hypothetical poBackSlice), to hint the operation 
happens at head (because "pop" alone means at back). But as others have said 
"front" in the context of ranges has now an established sense of "first" (just 
like "head" or "car" for lists, by the way), or maybe more exactly "current".

Denis
-- 
_________________
vita es estrany
spir.wikidot.com