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