Hi richard BTW guille found your prolog bookon second hand :)
My own Smalltalk library (and yes, I've tried to put it on github, I don't know what I'm doing wrong)
If you want we can get with it. Just ask and we can do a videos sessions with zoom,m webex, team or whatever software.
includes Deque and BoundedDeque, both descendants of Collection. Using addLast/removeLast gives you a stack (use #last for peeking) Using addLast/removeFirst gives you a queue. (use #first for peeking)
I have found on my disc astc-1711 but I could not find them. Can you send us the files?
(1) I am puzzled why there are separate FIFO and LIFO classes rather than a single BoundedDeque. -- This has implications for performance. (2) I am puzzled why #withCapacity: is used rather than #new:, familiar from OrderedCollection.
Good point
-- These two points together make it hard to just swap OrderedCollection and ?IFOBuffer.
(3) I am puzzled why #clear is used instead of the familiar #removeAll. -- See note on question 2.
Good point this is nice for API with Collection.
(4) I am extremely puzzled why ALL, like ALL, of the internals of the data structure are exposed. Did encapsulation fall out of favour and I didn't get the memo? (5) It looks as though calling #capacity: at the wrong time can destroy the integrity of one of these containers, but there is nothing sayiing "don't do that". (6) I am puzzled that they are not Collections.
What do you mean. If this is that they do not inherit from Collection I can understand because the API of collection is large. Now Alok it would be good to look at ANSI and see a bit the protocol I attach ANSI 
(7) I am puzzled why trying to access an element in an empty buffer does not signal a CollectionIsEmpty exception -- Is this related to (6)?
The structure, with two separate classes and key performance-essential methods being template methods, hurts performance by about a factor of two in my tests.
Now Pharo has a design MOOC and if Stephane Ducasse says "this is great", these things that puzzle me must be good design. I would like to improve my skills, so *why* is this good design? (As it happens, I *have* had occasion to 'push' from both ends of a single Deque.)
I say great because any effort is good, Then we can discuss. Iâm currently running a summerschool in parallel to prepare several talks to ESUG and finishing the organisation and reviewing other code and more. :)
None of this is meant as criticism of the generosity or competence of the authors. It expresses genuine puzzlement. Like when I implemented deques I could not imagine not making them Collections. Principle of Least Surprise and all that. Maybe I should be thinking differently.
On Fri, 27 Jun 2025 at 20:10, stephane ducasse via Pharo-users <pharo-users@lists.pharo.org> wrote:
Thanks this is great!
On 18 Jun 2025, at 12:13, Alok via Pharo-users <pharo-users@lists.pharo.org> wrote:
Hello Everyone, We're excited to share a new addition to the pharo-containers. An efficient Circular Buffer implementation, developed as part of Google Summer of Code 2025 project under the mentorship of Gordana Rakic and Sebastian Jordan Montaño.
This package provides fixed-size buffers supporting both FIFO (queue-style) and LIFO (stack-style) behavior. Itâs designed for use cases such as streaming data, undo/redo functionality, chat or browser history & more.
You can find the repo here: Containers-Buffer The README includes usage examples, installation steps etc.
Feedback, suggestions, and contributions are very welcome ! ThankYou ! Alok Pathak GSoC'25 Contributor
Stéphane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73
"If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes
Stéphane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73 "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes