Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #22443 > unrolled thread

BlueJ don't know what i did wrong

Back to article view | Back to comp.lang.java.programmer

Contents

  BlueJ don't know what i did wrong BlueJguywithoutskill <marvin.radke@htp-tel.de> - 2013-02-22 06:03 -0800
    Re: BlueJ don't know what i did wrong Joerg Meier <joergmmeier@arcor.de> - 2013-02-22 15:55 +0100
    Re: BlueJ don't know what i did wrong marvin.radke@htp-tel.de - 2013-02-22 07:13 -0800
      Re: BlueJ don't know what i did wrong Joerg Meier <joergmmeier@arcor.de> - 2013-02-22 16:24 +0100
        Re: BlueJ don't know what i did wrong marvin.radke@htp-tel.de - 2013-02-22 07:31 -0800
        Re: BlueJ don't know what i did wrong Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-02-22 10:50 -0500
    Re: BlueJ don't know what i did wrong markspace <markspace@nospam.nospam> - 2013-02-22 10:43 -0800
    Re: BlueJ don't know what i did wrong marvin.radke@htp-tel.de - 2013-02-24 02:27 -0800
      Re: BlueJ don't know what i did wrong Joerg Meier <joergmmeier@arcor.de> - 2013-02-24 14:54 +0100
        Re: BlueJ don't know what i did wrong marvin.radke@htp-tel.de - 2013-02-24 06:15 -0800
      Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-24 15:04 +0000
      Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-24 16:29 +0000
        Re: BlueJ don't know what i did wrong Joerg Meier <joergmmeier@arcor.de> - 2013-02-24 18:21 +0100
          Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-24 17:43 +0000
            Re: BlueJ don't know what i did wrong Joerg Meier <joergmmeier@arcor.de> - 2013-02-24 20:04 +0100
              Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-24 19:24 +0000
                Re: BlueJ don't know what i did wrong marvin.radke@htp-tel.de - 2013-02-25 01:52 -0800
                  Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-25 11:10 +0000
                    Re: BlueJ don't know what i did wrong "John B. Matthews" <nospam@nospam.invalid> - 2013-02-25 07:50 -0500
                      Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-25 13:35 +0000
                        Re: BlueJ don't know what i did wrong "John B. Matthews" <nospam@nospam.invalid> - 2013-02-25 13:52 -0500
                          Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-25 19:54 +0000
                            Re: BlueJ don't know what i did wrong Lew <lewbloch@gmail.com> - 2013-02-25 14:26 -0800
                              Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-26 09:08 +0000
                            Re: BlueJ don't know what i did wrong Arne Vajhøj <arne@vajhoej.dk> - 2013-02-25 22:05 -0500
                            Re: BlueJ don't know what i did wrong Arne Vajhøj <arne@vajhoej.dk> - 2013-02-25 22:08 -0500
                              Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-26 09:23 +0000
                                Re: BlueJ don't know what i did wrong Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-26 05:59 -0400
                                  Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-26 11:30 +0000
                                    Re: BlueJ don't know what i did wrong Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-27 06:45 -0400
                                      Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-27 11:58 +0000
                                      Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-27 12:24 +0000
                                        Re: BlueJ don't know what i did wrong Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-27 22:40 -0400
                                          Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-28 08:53 +0000
                                            Re: BlueJ don't know what i did wrong Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-28 17:14 -0400
                                              Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-03-01 08:45 +0000
                                  Re: BlueJ don't know what i did wrong markspace <markspace@nospam.nospam> - 2013-02-26 08:33 -0800
                            Re: BlueJ don't know what i did wrong Arne Vajhøj <arne@vajhoej.dk> - 2013-02-25 22:19 -0500
                        Re: BlueJ don't know what i did wrong Arne Vajhøj <arne@vajhoej.dk> - 2013-02-25 22:02 -0500
                    Re: BlueJ don't know what i did wrong marvin.radke@htp-tel.de - 2013-02-25 09:54 -0800
                      Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-25 18:25 +0000
                    Re: BlueJ don't know what i did wrong Joerg Meier <joergmmeier@arcor.de> - 2013-02-26 16:13 +0100
                      Re: BlueJ don't know what i did wrong lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-26 16:40 +0000
                        Re: BlueJ don't know what i did wrong Joerg Meier <joergmmeier@arcor.de> - 2013-02-26 18:19 +0100
                  Re: BlueJ don't know what i did wrong markspace <markspace@nospam.nospam> - 2013-02-25 08:34 -0800
      Re: BlueJ don't know what i did wrong Lew <lewbloch@gmail.com> - 2013-02-24 12:38 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#22511

In article <PqydnQ_Wh-MT9bbMnZ2dnUVZ8tGdnZ2d@bt.com>,
 lipska the kat <"nospam at neversurrender dot co dot uk"> wrote:

> On 25/02/13 12:50, John B. Matthews wrote:
> > In article<veSdnb08Iq8m27bMnZ2dnUVZ8g2dnZ2d@bt.com>,
> >   lipska the kat<"nospam at neversurrender dot co dot uk">  wrote:
> >
> >> <http://docs.oracle.com/javase/6/docs/api/java/util/Stack.html>
> >>
> >> <pseudo-code>
> >>
> >> Stack s = new Stack()
> >> ...
> >> </pseudo-code>
> >
> > Please don't recommend raw types for new code, and don't recommend 
> > an API that says explicitly, "A more complete and consistent set of 
> > LIFO stack operations is provided by the Deque interface and its 
> > implementations, which should be used in preference to this class."
> 
> Did you miss the <pseudo-code> bit?

No; it was you who cited java.util.Stack<E>.

[...]

> The documentation for Deque states, "A linear collection that 
> supports element insertion and removal at both ends." Not exactly 
> stack like is it?

Further along it states, "Deques can also be used as LIFO (Last-In- 
First-Out) stacks. This interface should be used in preference to the 
legacy Stack class."

> It's the idea, not the actual implementation that is important.

Both seem important to me.

> If the OP can read he can figure the rest out for himself.

Yes, a trip to the API is never wasted. I had recently stumbled over 
this very issue, incorrectly thinking that an implementation of Queue<E> 
was sufficient to simulate a stack.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#22512

On 25/02/13 18:52, John B. Matthews wrote:
> In article<PqydnQ_Wh-MT9bbMnZ2dnUVZ8tGdnZ2d@bt.com>,
>   lipska the kat<"nospam at neversurrender dot co dot uk">  wrote:
>
>> On 25/02/13 12:50, John B. Matthews wrote:
>>> In article<veSdnb08Iq8m27bMnZ2dnUVZ8g2dnZ2d@bt.com>,
>>>    lipska the kat<"nospam at neversurrender dot co dot uk">   wrote:
>>>
>>>> <http://docs.oracle.com/javase/6/docs/api/java/util/Stack.html>
>>>>
>>>> <pseudo-code>
>>>>
>>>> Stack s = new Stack()
>>>> ...
>>>> </pseudo-code>
>>>
>>> Please don't recommend raw types for new code, and don't recommend
>>> an API that says explicitly, "A more complete and consistent set of
>>> LIFO stack operations is provided by the Deque interface and its
>>> implementations, which should be used in preference to this class."

Why? why use a Deque instead of a Stack? ... because the documentation 
says so? ... A Stack is an abstraction, it's a very widely understood 
abstraction, everyone who has ever read a book on software knows what a 
stack is. push, pop, peek, they are Stack methods, you don't need 
anything else for a Stack, even peek is questionable. Providing a method 
to add something to the bottom of a Stack doesn't make sense in terms of 
the 'stackness' of a Stack. It just adds meaningless and unneeded 
complexity and confusion, particularly for a beginner to Java.

If you are reading someone else's code and you see

Stack s = new Stack();

you know EXACTLY what to expect. What are you to expect when you see a 
Deque ... could be anything.

Can you give me one good reason to use a Deque instead of a Stack when a 
stack is what I want apart from "because the documentation says so"

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#22515

lipska the kat wrote:
> Can you give me one good reason to use a Deque instead of a Stack when a 
> stack is what I want apart from "because the documentation says so"

You already rejected one good reason. Why give you another?

You can look this up for yourself, anyway.
http://lmgtfy.com/?q=Java+why+use+Deque+instead+of+Stack

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#22521

On 25/02/13 22:26, Lew wrote:
> lipska the kat wrote:
>> Can you give me one good reason to use a Deque instead of a Stack when a
>> stack is what I want apart from "because the documentation says so"
>
> You already rejected one good reason. Why give you another?

Ah yes, the Orwellian approach
Deque is the Java equivalent of that Orwellian concept, newspeak
Deque is double plus good because The Party says so

> You can look this up for yourself, anyway.
> http://lmgtfy.com/?q=Java+why+use+Deque+instead+of+Stack

Opinions differ, are you incapable of making your mind up on your own?
Is your entire value system built on the results of a Google search?
Think about it for a minute, try to take a broader view.

Do Oracle/Sun/whoever recommend Deque because Stack inappropriately 
extends Vector or because Deque doesn't allow indexed addressing?
I'd suggest the former, although we can't be sure can we, as all we have 
is a line in a javadoc.

Do you understand the concept of abstraction?
Do you understand the concept of programming by contract?

If you do you will understand my reluctance to use a Deque in place of a 
Stack.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#22518

On 2/25/2013 2:54 PM, lipska the kat wrote:
> On 25/02/13 18:52, John B. Matthews wrote:
>> In article<PqydnQ_Wh-MT9bbMnZ2dnUVZ8tGdnZ2d@bt.com>,
>>   lipska the kat<"nospam at neversurrender dot co dot uk">  wrote:
>>
>>> On 25/02/13 12:50, John B. Matthews wrote:
>>>> In article<veSdnb08Iq8m27bMnZ2dnUVZ8g2dnZ2d@bt.com>,
>>>>    lipska the kat<"nospam at neversurrender dot co dot uk">   wrote:
>>>>
>>>>> <http://docs.oracle.com/javase/6/docs/api/java/util/Stack.html>
>>>>>
>>>>> <pseudo-code>
>>>>>
>>>>> Stack s = new Stack()
>>>>> ...
>>>>> </pseudo-code>
>>>>
>>>> Please don't recommend raw types for new code, and don't recommend
>>>> an API that says explicitly, "A more complete and consistent set of
>>>> LIFO stack operations is provided by the Deque interface and its
>>>> implementations, which should be used in preference to this class."
>
> Why? why use a Deque instead of a Stack? ... because the documentation
> says so? ...

The authors of that documentation is the authors of the code.

It seems reasonable to expect them to know the domain pretty well.

>              A Stack is an abstraction, it's a very widely understood
> abstraction, everyone who has ever read a book on software knows what a
> stack is. push, pop, peek, they are Stack methods, you don't need
> anything else for a Stack, even peek is questionable. Providing a method
> to add something to the bottom of a Stack doesn't make sense in terms of
> the 'stackness' of a Stack. It just adds meaningless and unneeded
> complexity and confusion, particularly for a beginner to Java.
>
> If you are reading someone else's code and you see
>
> Stack s = new Stack();
>
> you know EXACTLY what to expect. What are you to expect when you see a
> Deque ... could be anything.

People reading Java Docs will know what it is.

People with CS background will know what a double ended queue is.

Arne

[toc] | [prev] | [next] | [standalone]

#22519

On 2/25/2013 2:54 PM, lipska the kat wrote:
> On 25/02/13 18:52, John B. Matthews wrote:
>> In article<PqydnQ_Wh-MT9bbMnZ2dnUVZ8tGdnZ2d@bt.com>,
>>   lipska the kat<"nospam at neversurrender dot co dot uk">  wrote:
>>
>>> On 25/02/13 12:50, John B. Matthews wrote:
>>>> In article<veSdnb08Iq8m27bMnZ2dnUVZ8g2dnZ2d@bt.com>,
>>>>    lipska the kat<"nospam at neversurrender dot co dot uk">   wrote:
>>>>
>>>>> <http://docs.oracle.com/javase/6/docs/api/java/util/Stack.html>
>>>>>
>>>>> <pseudo-code>
>>>>>
>>>>> Stack s = new Stack()
>>>>> ...
>>>>> </pseudo-code>
>>>>
>>>> Please don't recommend raw types for new code, and don't recommend
>>>> an API that says explicitly, "A more complete and consistent set of
>>>> LIFO stack operations is provided by the Deque interface and its
>>>> implementations, which should be used in preference to this class."
>
> Why? why use a Deque instead of a Stack? ... because the documentation
> says so? ... A Stack is an abstraction, it's a very widely understood
> abstraction, everyone who has ever read a book on software knows what a
> stack is. push, pop, peek, they are Stack methods, you don't need
> anything else for a Stack, even peek is questionable. Providing a method
> to add something to the bottom of a Stack doesn't make sense in terms of
> the 'stackness' of a Stack. It just adds meaningless and unneeded
> complexity and confusion, particularly for a beginner to Java.

You are aware that Stack<> provides elementAt, insertElementAt and
removeElementAt?

Arne

[toc] | [prev] | [next] | [standalone]

#22523

On 26/02/13 03:08, Arne Vajhøj wrote:
> On 2/25/2013 2:54 PM, lipska the kat wrote:
>> On 25/02/13 18:52, John B. Matthews wrote:
[snip]
>>
>> Why? why use a Deque instead of a Stack? ... because the documentation
>> says so? ... A Stack is an abstraction, it's a very widely understood
>> abstraction, everyone who has ever read a book on software knows what a
>> stack is. push, pop, peek, they are Stack methods, you don't need
>> anything else for a Stack, even peek is questionable. Providing a method
>> to add something to the bottom of a Stack doesn't make sense in terms of
>> the 'stackness' of a Stack. It just adds meaningless and unneeded
>> complexity and confusion, particularly for a beginner to Java.
>
> You are aware that Stack<> provides elementAt, insertElementAt and
> removeElementAt?

Y'know what Arne, you are quite predictable, it was a toss up between 
you and Lew as to who would point that out first ...  ding ! we have a 
winner.

Vector provides the methods you mention, not Stack ... and before you go 
into a long diatribe about inheritance you can save your breath, I'm 
fully aware of those implications.

If you use Vector methods on a Stack then you are intentionally breaking 
the contract of Stack. This is simply poor coding practice, it makes 
your code harder to read and maintain and exposes a confused 
understanding of abstraction. If you want Vector methods use a Vector, 
if you want a Stack, use a Stack. It constantly amazes me that 
supposedly experienced developers don't understand this simple, 
fundamental rule of Object Oriented Software Design.

What's the contract of Deque ... a double ended queue?
That in itself breaks the (humanly acceptable) contract of Queue.
If a Queue is double ended it's not (conceptually) a Queue is it?

Stack = LIFO
Queue = FIFO

Anything else isn't

Maybe it would have been better if a Stack had been implemented by 
Composition WITH Vector rather by extension OF Vector ...

But if we have inheritance why not use it eh?
(that's a rhetorical question).

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#22524

On 02/26/2013 05:23 AM, lipska the kat wrote:
[ SNIP ]

> What's the contract of Deque ... a double ended queue?
> That in itself breaks the (humanly acceptable) contract of Queue.
> If a Queue is double ended it's not (conceptually) a Queue is it?
>
> Stack = LIFO
> Queue = FIFO
>
> Anything else isn't
[ SNIP ]

>
> lipska
>
A deque (double ended queue) is a queue generalization. Despite the 
name, a deque is not a queue, but a queue is a deque. If you use a deque 
as a queue or a stack, then you use it appropriately.

You made a point of using things appropriately by saying "If you use 
Vector methods on a Stack then you are intentionally breaking the 
contract of Stack". The same applies to stack or queue usages of Deque; 
in the latter case since Deque implements Queue, you work through the 
lens of Queue. If wanting stack behaviour, you use the Deque methods 
that are intended for stack behaviour. Exactly what you were advising.

AHS

[toc] | [prev] | [next] | [standalone]

#22525

On 26/02/13 09:59, Arved Sandstrom wrote:
> On 02/26/2013 05:23 AM, lipska the kat wrote:
> [ SNIP ]
>
>> What's the contract of Deque ... a double ended queue?
>> That in itself breaks the (humanly acceptable) contract of Queue.
>> If a Queue is double ended it's not (conceptually) a Queue is it?
>>
>> Stack = LIFO
>> Queue = FIFO
>>
>> Anything else isn't
> [ SNIP ]
>
>>
>> lipska
>>
> A deque (double ended queue) is a queue generalization. Despite the
> name, a deque is not a queue, but a queue is a deque.

You have this the wrong way round I'm afraid.
A Deque 'is a' Queue because it extends Queue, you can call Queue 
methods on Deque but you cannot call Deque methods on Queue.
A Queue is most definitely NOT a Deque.

These are first year comp sci concepts really.

A Queue is Fist In First Out, I can't see any reasonable description of 
Queue being anything else.

We all know what Queue is, if you want to change the definition of Queue 
then you need to call it something else, for example a PriorityQueue has 
nodes that contain the queued item plus a priority, it's not a Queue is 
it? it's a PriorityQueue.

Pedantic? well yes, aren't computers the ultimate pedants?

A Deque is a what ... Anything in, anything out any time, and no, it 
doesn't have an index but it does have removeFirstOccurrence and 
removeLastOccurrence which are as close as you can get to random access 
as to make no odds.

It's muddy, confused design

> You made a point of using things appropriately by saying "If you use
> Vector methods on a Stack then you are intentionally breaking the
> contract of Stack". The same applies to stack or queue usages of Deque;

But it isn't, can't you see, first order methods on Stack are Stack type 
methods, first order methods on Deque are ... what exactly, a whole 
bunch of duplicated methods of Stack and Queue and who knows what else

> in the latter case since Deque implements Queue,

Deque *extends* Queue, they are both interfaces (I'm reading the API 
docs here)

> you work through the
> lens of Queue. If wanting stack behaviour, you use the Deque methods
> that are intended for stack behaviour. Exactly what you were advising.

Yea, well we are coming up against the Law of Diminishing returns here I 
think.

The contract of an interface is the collection of methods it publishes.

[where interface = Interface or Class or Enum etc]

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#22569

On 02/26/2013 07:30 AM, lipska the kat wrote:
> On 26/02/13 09:59, Arved Sandstrom wrote:
>> On 02/26/2013 05:23 AM, lipska the kat wrote:
>> [ SNIP ]
>>
>>> What's the contract of Deque ... a double ended queue?
>>> That in itself breaks the (humanly acceptable) contract of Queue.
>>> If a Queue is double ended it's not (conceptually) a Queue is it?
>>>
>>> Stack = LIFO
>>> Queue = FIFO
>>>
>>> Anything else isn't
>> [ SNIP ]
>>
>>>
>>> lipska
>>>
>> A deque (double ended queue) is a queue generalization. Despite the
>> name, a deque is not a queue, but a queue is a deque.
>
> You have this the wrong way round I'm afraid.
> A Deque 'is a' Queue because it extends Queue, you can call Queue
> methods on Deque but you cannot call Deque methods on Queue.
> A Queue is most definitely NOT a Deque.
>
> These are first year comp sci concepts really.
[ SNIP ]

You want to read up on generalization and specialization.

AHS

[toc] | [prev] | [next] | [standalone]

#22572

On 27/02/13 10:45, Arved Sandstrom wrote:
> On 02/26/2013 07:30 AM, lipska the kat wrote:
>> On 26/02/13 09:59, Arved Sandstrom wrote:
>>> On 02/26/2013 05:23 AM, lipska the kat wrote:

[snip]

>>>>
>>> A deque (double ended queue) is a queue generalization. Despite the
>>> name, a deque is not a queue, but a queue is a deque.
>>
>> You have this the wrong way round I'm afraid.
>> A Deque 'is a' Queue because it extends Queue, you can call Queue
>> methods on Deque but you cannot call Deque methods on Queue.
>> A Queue is most definitely NOT a Deque.
>>
>> These are first year comp sci concepts really.
> [ SNIP ]
>
> You want to read up on generalization and specialization.

======================= Generalization ==============================
http://en.wikipedia.org/wiki/Generalisation

... concept A(Queue) is considered a "generalization" of concept 
B(Deque) if and only if:

every instance of concept B (Deque) is also an instance of concept A 
(Queue); -- this is obviously the case as Deque extends Queue

and

there are instances of concept A(Queue) which are not instances of 
concept B(Deque) -- again true, you can't call Deque methods on Queue types
======================================================================

You appear to be arguing against this with your assertion that
"A deque (double ended queue) is a queue generalization"

In fact a Deque is a Queue *specialization*

============================ Specialization ==========================
http://en.wikipedia.org/wiki/Specialization_%28logic%29

... Concept B(Deque) is a "specialisation" of concept A(Queue) if and 
only if:

every instance of concept B (Deque) is also an instance of concept A 
(Queue); and

there are instances of concept A(Queue) which are not instances of 
concept B(Deque).

---see above
=====================================================================

Still not convinced ?

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#22574

On 27/02/13 10:45, Arved Sandstrom wrote:
> On 02/26/2013 07:30 AM, lipska the kat wrote:
>> On 26/02/13 09:59, Arved Sandstrom wrote:
>>> On 02/26/2013 05:23 AM, lipska the kat wrote:
>>> [ SNIP ]
>>>
>>>> What's the contract of Deque ... a double ended queue?
>>>> That in itself breaks the (humanly acceptable) contract of Queue.
>>>> If a Queue is double ended it's not (conceptually) a Queue is it?
>>>>
>>>> Stack = LIFO
>>>> Queue = FIFO
>>>>
>>>> Anything else isn't
>>> [ SNIP ]
>>>
>>>>
>>>> lipska
>>>>
>>> A deque (double ended queue) is a queue generalization. Despite the
>>> name, a deque is not a queue, but a queue is a deque.
>>
>> You have this the wrong way round I'm afraid.
>> A Deque 'is a' Queue because it extends Queue, you can call Queue
>> methods on Deque but you cannot call Deque methods on Queue.
>> A Queue is most definitely NOT a Deque.
>>
>> These are first year comp sci concepts really.
> [ SNIP ]
>
> You want to read up on generalization and specialization.

On the other hand and discussing C++;

http://www.brpreiss.com/books/opus4/html/page158.html

Specialization
The more general abstraction is the base class and the restricted 
abstraction is the derived class. E.g., when using specialization we 
would derive the class Queue from the class Deque thus:
class Queue : public Deque { ... };
The Queue class interface should restrict access to only those base 
class member functions that are appropriate.

Generalization
The more restricted abstraction is the base class from which the more 
general abstraction is derived. E.g., when using generalization we would 
derive the class Deque from the class Queue thus:
class Deque : public Queue { ... };
The Deque class inherits and generalizes the interface of the Queue class.

appears to be at odds with my earlier assertion

So, does either definition make your assertion

"a deque is not a queue, but a queue is a deque"

true?

No it does not

In the Java programming language, and where Deque extends Queue

a Deque *is* a Queue

and

a Queue *is not* a Deque

regardless of which definition of Specialization and Generalization you use.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#22606

On 02/27/2013 08:24 AM, lipska the kat wrote:
> On 27/02/13 10:45, Arved Sandstrom wrote:
>> On 02/26/2013 07:30 AM, lipska the kat wrote:
>>> On 26/02/13 09:59, Arved Sandstrom wrote:
>>>> On 02/26/2013 05:23 AM, lipska the kat wrote:
>>>> [ SNIP ]
>>>>
>>>>> What's the contract of Deque ... a double ended queue?
>>>>> That in itself breaks the (humanly acceptable) contract of Queue.
>>>>> If a Queue is double ended it's not (conceptually) a Queue is it?
>>>>>
>>>>> Stack = LIFO
>>>>> Queue = FIFO
>>>>>
>>>>> Anything else isn't
>>>> [ SNIP ]
>>>>
>>>>>
>>>>> lipska
>>>>>
>>>> A deque (double ended queue) is a queue generalization. Despite the
>>>> name, a deque is not a queue, but a queue is a deque.
>>>
>>> You have this the wrong way round I'm afraid.
>>> A Deque 'is a' Queue because it extends Queue, you can call Queue
>>> methods on Deque but you cannot call Deque methods on Queue.
>>> A Queue is most definitely NOT a Deque.
>>>
>>> These are first year comp sci concepts really.
>> [ SNIP ]
>>
>> You want to read up on generalization and specialization.
>
> On the other hand and discussing C++;
>
> http://www.brpreiss.com/books/opus4/html/page158.html
>
> Specialization
> The more general abstraction is the base class and the restricted
> abstraction is the derived class. E.g., when using specialization we
> would derive the class Queue from the class Deque thus:
> class Queue : public Deque { ... };
> The Queue class interface should restrict access to only those base
> class member functions that are appropriate.
>
> Generalization
> The more restricted abstraction is the base class from which the more
> general abstraction is derived. E.g., when using generalization we would
> derive the class Deque from the class Queue thus:
> class Deque : public Queue { ... };
> The Deque class inherits and generalizes the interface of the Queue class.
>
> appears to be at odds with my earlier assertion
>
> So, does either definition make your assertion
>
> "a deque is not a queue, but a queue is a deque"
>
> true?
>
> No it does not
>
> In the Java programming language, and where Deque extends Queue
>
> a Deque *is* a Queue
>
> and
>
> a Queue *is not* a Deque
>
> regardless of which definition of Specialization and Generalization you
> use.
>
> lipska
>
I'm happy with the definition that for example Knuth or Sedgwick use 
(and about a million other people), where a deque is called a 
generalization of a queue or a stack. The reason a deque is called a 
generalization of a queue or a stack is because it is in fact more 
general than a queue or a stack, and combines features of both.

Since a whole raft of CS authorities and other programming commentators 
are happy to call the deque a generalization of a queue or stack when 
writing about data structures, I'm pretty happy to accept this as a 
definition.

Don't get Java interface implementation aka UML realization mixed up 
with generalization. Deque is a generalization of Queue and Stack 
because it has characteristics of both; that's why you can use a Deque 
as either a Queue or a Stack. The business of Java interface Deque 
extending Java interface Queue, since doing things like that is the 
closest thing that Java has to multiple inheritance, is actually 
generalization, where Queue is the specialization of Deque.

AHS

[toc] | [prev] | [next] | [standalone]

#22610

On 28/02/13 02:40, Arved Sandstrom wrote:
> On 02/27/2013 08:24 AM, lipska the kat wrote:
>> On 27/02/13 10:45, Arved Sandstrom wrote:
>>> On 02/26/2013 07:30 AM, lipska the kat wrote:
>>>> On 26/02/13 09:59, Arved Sandstrom wrote:
>>>>> On 02/26/2013 05:23 AM, lipska the kat wrote:

[snip]

> I'm happy with the definition that for example Knuth or Sedgwick use
> (and about a million other people), where a deque is called a
> generalization of a queue or a stack. The reason a deque is called a
> generalization of a queue or a stack is because it is in fact more
> general than a queue or a stack, and combines features of both.
>
> Since a whole raft of CS authorities and other programming commentators
> are happy to call the deque a generalization of a queue or stack when
> writing about data structures, I'm pretty happy to accept this as a
> definition.

Yep, I agree, my stubborn determination to prove you wrong about this 
issue clouded my judgment. On this I concede. I am human, I am 
imperfect, I make mistakes.

However

I simply cannot agree with your assertion that

"a deque is not a queue, but a queue is a deque."

Enter the following into your favorite IDE

java.util.Queue queue = null;
java.util.Deque deque = null;
		
queue = deque;
//This compiles: Because we can store a reference to a Deque into a 
//reference to a Queue, a Deque *is a* Queue

deque = queue;
//This does not compile: Because we can't store a reference
//to a Queue into a reference to a Deque, a Queue *is not* a Deque

If a Queue were a Deque then we could call Deque methods on a Queue
Can we call Deque methods on a Queue? well I can't, can you?

I'd be interested to hear your thoughts on this.

lipska




-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#22632

On 02/28/2013 04:53 AM, lipska the kat wrote:
> On 28/02/13 02:40, Arved Sandstrom wrote:
>> On 02/27/2013 08:24 AM, lipska the kat wrote:
>>> On 27/02/13 10:45, Arved Sandstrom wrote:
>>>> On 02/26/2013 07:30 AM, lipska the kat wrote:
>>>>> On 26/02/13 09:59, Arved Sandstrom wrote:
>>>>>> On 02/26/2013 05:23 AM, lipska the kat wrote:
>
> [snip]
>
>> I'm happy with the definition that for example Knuth or Sedgwick use
>> (and about a million other people), where a deque is called a
>> generalization of a queue or a stack. The reason a deque is called a
>> generalization of a queue or a stack is because it is in fact more
>> general than a queue or a stack, and combines features of both.
>>
>> Since a whole raft of CS authorities and other programming commentators
>> are happy to call the deque a generalization of a queue or stack when
>> writing about data structures, I'm pretty happy to accept this as a
>> definition.
>
> Yep, I agree, my stubborn determination to prove you wrong about this
> issue clouded my judgment. On this I concede. I am human, I am
> imperfect, I make mistakes.
>
> However
>
> I simply cannot agree with your assertion that
>
> "a deque is not a queue, but a queue is a deque."
>
> Enter the following into your favorite IDE
>
> java.util.Queue queue = null;
> java.util.Deque deque = null;
>
> queue = deque;
> //This compiles: Because we can store a reference to a Deque into a
> //reference to a Queue, a Deque *is a* Queue
>
> deque = queue;
> //This does not compile: Because we can't store a reference
> //to a Queue into a reference to a Deque, a Queue *is not* a Deque
>
> If a Queue were a Deque then we could call Deque methods on a Queue
> Can we call Deque methods on a Queue? well I can't, can you?
>
> I'd be interested to hear your thoughts on this.
>
> lipska

I'm not sure I agree with one of my original statements either, now that 
I really think things through.

We're talking several different notions of "generalization". These 
conflict pretty badly. Sticking with generalization as in generalization 
& specialization, and supertypes and subtypes, on second thought I'd 
have to agree with you.

A deque is a generalization of queue and stack in the sense that it is 
more general; it has the operations to support use as either a queue or 
a stack. It's multiple inheritance (conceptually if not for real) that 
gives us this mix.

This was an interesting discussion. I now want to go and pound nails 
into my forehead. Just goes to show that a body needs to be really 
careful about CS statements like "a deque is a generalization of queue 
and stack", because in UML/OO terms it's actually not.

AHS

[toc] | [prev] | [next] | [standalone]

#22648

On 28/02/13 21:14, Arved Sandstrom wrote:
> On 02/28/2013 04:53 AM, lipska the kat wrote:
>> On 28/02/13 02:40, Arved Sandstrom wrote:
>>> On 02/27/2013 08:24 AM, lipska the kat wrote:
>>>> On 27/02/13 10:45, Arved Sandstrom wrote:
>>>>> On 02/26/2013 07:30 AM, lipska the kat wrote:
>>>>>> On 26/02/13 09:59, Arved Sandstrom wrote:
>>>>>>> On 02/26/2013 05:23 AM, lipska the kat wrote:

[snip]

> I'm not sure I agree with one of my original statements either, now that
> I really think things through.
>
> We're talking several different notions of "generalization". These
> conflict pretty badly. Sticking with generalization as in generalization
> & specialization, and supertypes and subtypes, on second thought I'd
> have to agree with you.
>
> A deque is a generalization of queue and stack in the sense that it is
> more general; it has the operations to support use as either a queue or
> a stack. It's multiple inheritance (conceptually if not for real) that
> gives us this mix.
>
> This was an interesting discussion. I now want to go and pound nails
> into my forehead.

[snip]

Heh heh, maybe we can compare scars :-)

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#22538

On 2/26/2013 1:59 AM, Arved Sandstrom wrote:
>>
> A deque (double ended queue) is a queue generalization.

Also a pun, I think.  A deque (pronounced "deck") is something you can 
deal from both ends of....

[toc] | [prev] | [next] | [standalone]

#22520

On 2/25/2013 2:54 PM, lipska the kat wrote:
> Can you give me one good reason to use a Deque instead of a Stack when a
> stack is what I want apart from "because the documentation says so"

Stack<> extends Vector<> and:
* Vector<> is replaced by ArrayList<>
* it means that there is indexed access to elements

2

Deque<> is an interface:
* it is possible to chose between different implementations
* implementation specific methods hidden

4

Arne

[toc] | [prev] | [next] | [standalone]

#22517

On 2/25/2013 8:35 AM, lipska the kat wrote:
> On 25/02/13 12:50, John B. Matthews wrote:
>> In article<veSdnb08Iq8m27bMnZ2dnUVZ8g2dnZ2d@bt.com>,
>>   lipska the kat<"nospam at neversurrender dot co dot uk">  wrote:
>>
>>> <http://docs.oracle.com/javase/6/docs/api/java/util/Stack.html>
>>>
>>> <pseudo-code>
>>>
>>> Stack s = new Stack()
>>> ...
>>> </pseudo-code>
>>
>> Please don't recommend raw types for new code, and don't recommend an
>> API that says explicitly, "A more complete and consistent set of LIFO
>> stack operations is provided by the Deque interface and its
>> implementations, which should be used in preference to this class."
>
> Did you miss the <pseudo-code> bit?
>
> Any text book on data structures will detail a Stack
> How many will discuss a Deque

The good ones will.

Double ended queue is a well known data structure.

> The documentation for Deque states
>
> "A linear collection that supports element insertion and removal at both
> ends"
>
> Not exactly stack like is it?

Read more:

<quote>
...
This interface extends the Queue interface. When a deque is used as a 
queue, FIFO (First-In-First-Out) behavior results. Elements are added at 
the end of the deque and removed from the beginning. The methods 
inherited from the Queue interface are precisely equivalent to Deque 
methods as indicated in the following table:
...
Deques can also be used as LIFO (Last-In-First-Out) stacks. This 
interface should be used in preference to the legacy Stack class. When a 
deque is used as a stack, elements are pushed and popped from the 
beginning of the deque. Stack methods are precisely equivalent to Deque 
methods as indicated in the table below:
...
</quote>

The last part actually says stack.

Arne

[toc] | [prev] | [next] | [standalone]

#22508

> <pseudo-code>
> 
> 
> 
> Stack s = new Stack()
> 
> 
> 
> //populate the stack
> 
> for(...){
> 
>     stack.push(someObject)
> 
> }
> 
> 
> 
> ... get a 'card'
> 
> 
> 
> SomeObject = stack.pop();
> 
> 
> 
> </pseudo-code>
> 
> 
> 
> This would avoid using the result of getting a value from the array as a 
> 
> test for your if/for/while conditionals
> 
> 
> 
> It might be worth a try

well i read the few things on the link and it seems like it could help, but through we only had very basic things in school, i don't know how to populate this stack... do i just have to insert vectors into it?

>If I understand what you are saying, then why not just add those cards 
>to the deck twice?  It's easier than keeping track of all cards in a 
>separate structure. 

but i would still need a counter (atleast a yes or no) if the card is already out or still avaiable or not?

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web