>> This works on a different principle than the linked list queue, but it >> does the same stuff. The main idea is that a "queue" can be anything, >> as long as it supports three operations: >> >> * isEmpty >> * insert >> * remove >> > <<snip>> > > Isn't there a fourth operation needed? > > * isFull
Hi Barry, If we add this requirement, then we're talking about a queue with bounds. That is a perfectly reasonable thing to ask for, and it may or may not be an essential property in applications that use queues, depending on our application. Small interfaces are easier to implement than large ones, so we should be try to put as few operations as necessary. In any case, I think we're straying from the main point, which is the idea that we can implement a concept in many different ways. The really simple ArrayQueue class presented earlier should "work" just like the LinkedQueue class. So in practical terms, if we needed a queue for some application, we can use the simple thing first. And if it turns out that the Queue implementation we've used is too slow, we can switch. No one should know the difference. (I wouldn't immediately use LinkedQueue only because I don't trust it. I mean that from an engineering point of view: the code has a heck of a lot of moving parts, and because I don't see a test suite for it, I can't be sure that it's correct without spending time on it. Queues are boring; I don't want to spend time on them unless I really need to. *grin*) Good programmming practice allows us to be non-committal in the places where we want to support change. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
