Queue push/pop
Brian Rice
water at tunes.org
Wed Jan 4 17:33:31 PST 2006
On Jan 4, 2006, at 5:03 PM, David Hopwood wrote:
> Brian Rice wrote:
>> On Jan 4, 2006, at 3:41 AM, Tony Garnock-Jones wrote:
>>
>>> (triggered by the changes to the process code to use push/pop
>>> instead of
>>> addLast/removeFirst)
>>>
>>> I don't like these names. Push and pop to me mean stack-like, LIFO
>>> behaviour. Using them to mean FIFO behaviour seems weird.
>>
>> These are used in standard textbooks for FIFO protocol, and we
>> use the
>> polymorphism in TraversalStream to shift between depth-first and
>> breadth-first traversals, so I think it's fair to say that we're
>> getting a benefit from the polymorphism. Also, LIFO and FIFO are not
>> the only possible animals where push:/pop are suitable protocols,
>> like
>> Heap's push:/pop which obey a sorting setup.
>>
>> It's weird, but on the other hand it's tedious to have code that
>> has to
>> indicate where first/last interplay in an explicit way. After
>> all, it
>> doesn't matter which is first and which is last, only that there is
>> FIFO semantics, in the same way that we don't really care that
>> Stack is
>> a Sequence whose "active" end is the "last"-word end of it.
>>
>> We can always add queries to indicate whether something is a LIFO
>> or FIFO.
>
> I would suggest leaving {push,pop} as they are now (with the latest
> change),
> and also supporting {addLast,addFirst,removeLast,removeFirst}.
>
> The allows the correct intent to be expressed for any given client:
> in some
> cases the intent is to push and pop without any dependency on
> order, and in
> others the order matters.
Yes, that's what we have already. The "instead of" was really more
about me changing how the client called the library. Although I also
copied over the Queue push:/pop wrapper methods to the SharedQueue,
with the eventual intent of turning that kind of thing into a Mixin
or Trait.
--
-Brian
http://tunes.org/~water/brice.vcf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060104/54427d1c/PGP.pgp
More information about the Slate
mailing list