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.jor...@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 > > > > > > >
