Ah, the astc copy you found is years out of date. And the deque.st you found has had several mistakes fixed since. Here's why it mattered to me that these data structures weren't Collections. I was writing my own testing and benchmarking code to explore these ones. They have #isEmpty, so naturally I used both #isEmpty and #notEmpty in my tests. Not collections, so #notEmpty isn't there. They have #do:. They don't have #print:, so I threw together some printing code using the conventional #do:separatedBy:. Not collections, so #do:separatedBy: isn't there. Throw in a few non-nil elements, check [b noneSatisfy: [:each | each isNil]] assert. Not collections, so #noneSatisfy: isn't there. Tried to preload a buffer with specified contents using #withAll:. Not a collection, so #withAll: isn't there. Tried to compare the result of a series of operations with the expected one. Not a collection, so #asArray isn't there. Now Collection is big. Collection selectors size ==> 201 Collection allSelectors size ==> 692 in Pharo 12. Collection selectors size ==> 403 Collection allSelectors size ==> 1091 in astc with everything included, including compatibility packages, and a lot of the methods in Collection don't make sense for all descendants. I've tried very very hard to reduce this in astc, so my Collection doesn't include #+ . Basically, in order to be a "good faith" Collection in astc, you have to be able to to #do: multiple times without changing the multiset of items reported and you have to report #size consistent with this. I finally understood why these buffers expose all their implementation details, and there is arguably an excellent reason for it. There is a question I would like advice about, and that's the best way (in Pharo) to accomplish the same purpose without exposing the implementation. Here's the reason. I think of unit tests as testing the externally visible behaviour of an object, so that unit tests should only use the public interface of the objects they're working with. One reason for this is that I want to be able to change the internal details completely without changing the tests. For example, another way to implement a deque is using a doubly linked list, and there's no reason that it couldn't be bounded, so a *FIFOBuffer might not *have* an elements array or a readIndex integer, and making such a change leaves the unit tests still useful. Well and good: there is *A* category of tests that can and should be restricted to the public interface. But the authors of these buffers went further. They decided to test that the operations do the right thing the right *way* and created further tests that check the internal state of a buffer after an operation. To do this, they need *access* to the internal state. It seems to me that there are three ways to do this. (1) Put the test code *inside* the class under test as an extension. Have the test code in the image only when testing. (2) Add the access-to-private-details methods in an extension, included in the image only when testing. (3) What the authors did: reveal all the implementation details to all the world all the time. A fourth theoretical possibility, providing the access-to-private-details methods to the test class(es) only, is easy in Eiffel but appears to be impossible in Smalltalk. At this point a confession is appropriate. While testing and benchmarking their code, I found a discrepancy between their results and mine, and it was MY code that was broken. (I had tested Deque, but didn't really care about BoundedDeque very much, so hadn't tested it very thoroughly.) My bug *was* revealed by a conventional public-interface-only test, but it would have been revealed quicker by a test-the-implementation test like theirs. So I doff my hat to the authors for their thoroughness. GIVEN then that testing the implementation as well as the interface is a good idea, which of the 3 approaches above is recommended? Is there a still better way? On Sun, 29 Jun 2025 at 16:18, stephane ducasse <stephane.ducasse@inria.fr> wrote:
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