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 >> >> >> >> >>
