Thnx a lot Richard for such great feedback. We'll definitely update the repo with all the necessary changes.

Thanks Stephane for sharing all the resources. I'll definitely go through ANSI :)


On Sun, 29 Jun, 2025, 13:40 Sebastian Jordan, <sebastian.jordan@inria.fr> wrote:
Hello Richard,

Thanks for your feedback. Just for context we are doing this project for the Google Summer of Code. I agree that the buffer should be polymorphic with the OrderedCollection.
Yes, we should signal empty collection when accesing ��an empty buffer (7)

We will rok on that and come back to you
Sebastian

Le 27 juin 2025 �� 12:23, Richard O'Keefe via Pharo-users <pharo-users@lists.pharo.org> a ��crit :

My own Smalltalk library (and yes, I've tried to put it on github, I
don't know what I'm doing wrong)
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)

(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.
������-- 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.
(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.
(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.)

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