Home > Archive > Smalltalk > January 2005 > queue in Smalltalk
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
queue in Smalltalk
|
|
| Guybrush Treepwood 2005-01-08, 8:57 am |
| I wanted to implement a queue in Smalltalk. I found this on the net:
Q8. How can I implement stack and queue operations in Smalltalk?
Ans. An OrderedCollection can be used to implement stack and queue
operations. A stack is implemented by using addLast: anObject and
removeLast methods for pushing and poping respectively. A Queue is
implemented by using addLast: anObject and removeFirst methods.
http://www.faqs.org/faqs/smalltalk-faq/
But if I inherit Queue from OrderedCollection, how can I prevent that the
other methods of OrderdCollection can not be called?
| |
|
| You can do it that way but why? Is it for school?
OrderedCollection already does what you need, use it like a queue.
| oc |
oc := OrderedCollection new.
oc
addLast: myObject;
addFirst: myOtherObject.
^oc
Change the name of the temp variable 'oc' to 'queue'.
-g
"Guybrush Treepwood" <schemer@hotmail.com> wrote in message
news:41dfd225$0$2683$ba620e4c@news.skynet.be...
> I wanted to implement a queue in Smalltalk. I found this on the net:
>
> Q8. How can I implement stack and queue operations in Smalltalk?
>
> Ans. An OrderedCollection can be used to implement stack and queue
>
> operations. A stack is implemented by using addLast: anObject and
>
> removeLast methods for pushing and poping respectively. A Queue is
>
> implemented by using addLast: anObject and removeFirst methods.
>
> http://www.faqs.org/faqs/smalltalk-faq/
>
> But if I inherit Queue from OrderedCollection, how can I prevent that the
> other methods of OrderdCollection can not be called?
>
>
>
>
| |
| Guybrush Treepwood 2005-01-08, 3:58 pm |
| Geoff wrote:
> You can do it that way but why? Is it for school?
>
The queue itself is not. But I want to use the queue in a larger project
that is for school yes.
| |
| Guybrush Treepwood 2005-01-08, 3:58 pm |
| Guybrush Treepwood wrote:
>
> But if I inherit Queue from OrderedCollection, how can I prevent that the
> other methods of OrderdCollection can not be called?
Correction, "can be called". I only want that those methods that represent a
queue action, can be called.
| |
| Hans-Martin Mosner 2005-01-08, 3:58 pm |
| Guybrush Treepwood <schemer@hotmail.com> wrote:
> Guybrush Treepwood wrote:
>
>
> Correction, "can be called". I only want that those methods that represent a
> queue action, can be called.
>
Then you should implement a wrapper object.
it should just implement the appropriate methods for your queue
(however you name them) and use an OrderedCollection and its methods
addFirst: and removeLast to implement the queue behavior.
Of course, better Smalltalk style is to use what's there. Have you
looked at the SharedQueue class already?
Cheers,
Hans-Martin
| |
| Guybrush Treepwood 2005-01-08, 3:58 pm |
| Hans-Martin Mosner wrote:
>
> Of course, better Smalltalk style is to use what's there. Have you
> looked at the SharedQueue class already?
>
Yes, but that's for multi-threading?
| |
| Hans-Martin Mosner 2005-01-08, 3:58 pm |
| Guybrush Treepwood <schemer@hotmail.com> wrote:
> Hans-Martin Mosner wrote:
> Yes, but that's for multi-threading?
>
So what? :-)
It works just as well with a single thread...
Cheers,
Hans-Martin
| |
| True Christian 2005-01-09, 3:57 am |
| "Guybrush Treepwood" <schemer@hotmail.com> wrote
>
> Correction, "can be called". I only want that those methods that represent
> a
> queue action, can be called.
Simply either subclass OrderedCollection and answer all the unwanted methods
with error messages or subclass Object using an OrderedCollection as an
instanceVariable and only allow messages you want. However for complete
purity you'd still need to block messages to Object methods.
| |
| Joachim Tuchel 2005-01-09, 3:57 pm |
| I'd say what you try to do there is simply breaking the rules of
inheritance. If there is a lot of methods in OrderedCollection that you
don't want to be used, you might not want to implement an "is-a" or "is
kind of" relationship between your queue and OrderedCollection. You
might introduce quite some problems into a system by using such a
construct which could be called subtractive inheritance...
Just because an OrderedCollectioon offers 2 or a handfull (of quite
many) methods that might be useful for your purposes, inheriting from an
OrderedCollection is surely no good idea.
Maybe you should think about using composition by adding the features of
OrderedCollection to a newly created class which only exhibits the
behaviour you really need and want users of the queue to use. Look at
composition and delegation and you might find a very handy solution.
Just my 2 cents
Joachim
| |
| Guybrush Treepwood 2005-01-09, 3:57 pm |
| Joachim Tuchel wrote:
> I'd say what you try to do there is simply breaking the rules of
> inheritance. If there is a lot of methods in OrderedCollection that you
> don't want to be used, you might not want to implement an "is-a" or "is
> kind of" relationship between your queue and OrderedCollection. You
> might introduce quite some problems into a system by using such a
> construct which could be called subtractive inheritance...
> Just because an OrderedCollectioon offers 2 or a handfull (of quite
> many) methods that might be useful for your purposes, inheriting from an
> OrderedCollection is surely no good idea.
>
Very true, hadn't thought about it that way.
> Maybe you should think about using composition by adding the features of
> OrderedCollection to a newly created class which only exhibits the
> behaviour you really need and want users of the queue to use. Look at
> composition and delegation and you might find a very handy solution.
>
> Just my 2 cents
>
> Joachim
I'll do.
| |
| Petr Vacha 2005-01-10, 8:58 am |
| Hi there,
the thing you're recommended to do (a wrapper) is one of so-called
Design Patterns. Look for Adapter (aka Wrapper) pattern in GoF (see
below).
Read some of these:
Gamma, Helm, Johnson, Vlissides: Design Patterns - Elements of
Reusable Object-Oriented Software
this book is often referenced as GoF (Gang of Four)
this one is this ultimate start to the topic
Buschmann, Meunier, Rohnert, Sommerlad, Stal: Pattern-Oriented Software
Architecture, Vol.1 - A System of Patterns (aka POSA1)
this one references GoF and overlaps it in some articles, I recommend
GoF to be read first.
Buschmann, Rohnert, Schmidt, Stal: Pattern-Oriented Software
Architecture, Vol.2 - Patterns for Concurrent and Networked Objects
(aka POSA2)
Read this one after those two, but it's not neccessary. Btw, you can
find there some useful things even if you're not going to develop
network or concurrent object system.
Petr Vacha
Guybrush Treepwood wrote:
> I wanted to implement a queue in Smalltalk. I found this on the net:
>
> Q8. How can I implement stack and queue operations in Smalltalk?
>
> Ans. An OrderedCollection can be used to implement stack and queue
>
> operations. A stack is implemented by using addLast: anObject and
>
> removeLast methods for pushing and poping respectively. A Queue is
>
> implemented by using addLast: anObject and removeFirst methods.
>
> http://www.faqs.org/faqs/smalltalk-faq/
>
> But if I inherit Queue from OrderedCollection, how can I prevent that the
> other methods of OrderdCollection can not be called?
>
>
>
>
| |
| Esteban A. Maringolo 2005-01-10, 8:58 am |
| True Christian escribió:
> "Guybrush Treepwood" <schemer@hotmail.com> wrote
>
>
>
> Simply either subclass OrderedCollection and answer all the unwanted methods
> with error messages or subclass Object using an OrderedCollection as an
> instanceVariable and only allow messages you want. However for complete
> purity you'd still need to block messages to Object methods.
And add type checking to that, right?
The responsiblity is of the sender, not the receiver.
If you sent to an integer a message that it is unable to understand,
the responsibility is yours. As much, the receiver will raise a DNU.
That's the simplicity of Smalltalk, and the elegance too, it's not
bloated with many constraints. It works more in a ecologic way.
The tree isn't in fault because it falls when cutted by a chainsaw,
it's the responsibility of who handles the chainsaw. Would you add
some chromosomes to the ADN of the tree to handle that kind of
situation, or will you teach the lumber man to lumber only when
appropiate. Think it in big scale and tell me which solutions solves
the real problem.
Best regards.
--
Esteban A. Maringolo
| |
| Can Altinbay 2005-01-10, 4:00 pm |
| "Guybrush Treepwood" <schemer@hotmail.com> wrote in message
news:41dfe47d$0$24442$ba620e4c@news.skynet.be...
> Guybrush Treepwood wrote:
>
the[color=darkred]
>
> Correction, "can be called". I only want that those methods that represent
a
> queue action, can be called.
>
Is there a real reason why the other methods should not be understood?
Otherwise, as another poster suggested, just use OrderedCollection.
| |
| Niall Ross 2005-01-11, 8:58 pm |
| Dear Guybrush,
I agree with Petr about the value of learning patterns. As you are
working in Smalltalk, you may find 'The Design Patterns Smalltalk Companion
(Alpert et al.) more convenient than GoF. You should also read Kent Beck's
'Smalltalk Best Practice Patterns' (if you haven't already).
Yours faithfully
Niall Ross
"Petr Vacha" <vacha@annexnet.cz> wrote in message
news:41e24efa@news.totallyobjects.com...
> Hi there,
> the thing you're recommended to do (a wrapper) is one of so-called
> Design Patterns. Look for Adapter (aka Wrapper) pattern in GoF (see
> below).
> Read some of these:
>
> Gamma, Helm, Johnson, Vlissides: Design Patterns - Elements of
> Reusable Object-Oriented Software
> this book is often referenced as GoF (Gang of Four)
> this one is this ultimate start to the topic
>
> Buschmann, Meunier, Rohnert, Sommerlad, Stal: Pattern-Oriented Software
> Architecture, Vol.1 - A System of Patterns (aka POSA1)
> this one references GoF and overlaps it in some articles, I recommend
> GoF to be read first.
>
> Buschmann, Rohnert, Schmidt, Stal: Pattern-Oriented Software
> Architecture, Vol.2 - Patterns for Concurrent and Networked Objects
> (aka POSA2)
> Read this one after those two, but it's not neccessary. Btw, you can
> find there some useful things even if you're not going to develop
> network or concurrent object system.
>
> Petr Vacha
>
>
> Guybrush Treepwood wrote:
>
the[color=darkred]
>
|
|
|
|
|