From: Ted Dennison<dennison@telepath.com>
Subject: Re: List container strawman
Date: Fri, 02 Nov 2001 15:06:37 GMT
Date: 2001-11-02T15:06:37+00:00 [thread overview]
Message-ID: <1EyE7.10050$xS6.13527@www.newsranger.com> (raw)
In-Reply-To: 9rti6v$hcu$1@news.huji.ac.il
In article <9rti6v$hcu$1@news.huji.ac.il>, Ehud Lamm says...
>1. In my scheme "Element" is a generic parameter of the top package
>(Containers), and not of the specific implementations.
>(Remember, my attemp for having interface inheritance)
I didn't do that because that is precisely what Booch does that makes it so
complicated to use. If one does that, then proper use of the package would
require 3 cascading generic package instantiations. If that is OK, then in my
opinion we should just bag this whole thing and use Booch.
>2. Why is List private? Shouldn't it be limited private, so we avoid
>possible erros caused by aliasing?
First off, I'd like to note for anyone who may have missed it, that any Element
passed in to be put on a list or taken off of one will be *copied*. Pointers to
elements will not be used.
If List were limited private, then we'd have to get rid of all those "&"
routines. My thinking was that Lisp-like functional list processing would be
desirable. You could indeed have aliasing problems, but only if your Element
type uses pointers. Having "&" avaliable also makes list operations somewhat
consistent with arrays, which also have "&".
However, any use of those "&" routines will involve creating a copy of every
element (much like using "&" with arrays does). That would probably be too
expensive in most cases, so perhaps it really isn't all that valuable. I'm
curious how others feel about this.
>(If the majority wants private, at least the spec should mention the
>possbile problems)
I can agree with this. At the least there should be some sort of warning in
there about using pointers in Element with those routines.
>3. "Construct" is indeed a long name. We can, as part of the library, decide
>on some standard name for this like - or +
As the comment said, I seriously considered that. However, it is not (yet) a
common idiom to use those for constructors. So I'm not sure if it would help or
hurt readability. Again, I'm curious what people think about this.
>4. I've seen many implemenations that paremtrize Insert and Remove with a
>direction parameter, instead of having seperate routines (_Back/_Front). I
>am not sure I know which approach I prefer...
>5. Front() and Back() raise execption on Empty List?
Assuming you are talking about the iterator routines "First" and "Last", that's
a good point. I seem to have totally neglected that case, and thus left serious
problems in there. For instance, the comment that says "For an empty list, First
= Last." is clearly wrong. That would indicate a list with one element, not an
empty one. I'll have to redo the iterators somehow...
>6. I like having a "No_More_Elements()" operation as part of the Iterator
>interface. It saves time compared to Size (for containers that don't keep
>count of size), and I don't like programming with exceptions ("exceptions
>for control flow").
That seems sensible. And I agree about using exceptions, which is why it is only
one example of 3. That stuff is all wrong anyway though...
>7. Sort should be in a child unit.
Why do you feel that way? What does putting it off in a separate unit gain you?
>
>Finally, a more general question:
>Is this a DeQueue or a Doubly-linked list? Should these be two different
>abstractions? (IMO: Yes, they should).
What specificly would the difference be?
Clearly it would have to be doubly-linked to support all those push and pop
operations, and both Next and Previous as iterators. You could implement those
on a singly-linked list, but it wouldn't be very efficient.
---
T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html
No trees were killed in the sending of this message.
However a large number of electrons were terribly inconvenienced.
next prev parent reply other threads:[~2001-11-02 15:06 UTC|newest]
Thread overview: 166+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-02 3:56 List container strawman Ted Dennison
2001-11-02 4:20 ` James Rogers
2001-11-02 14:23 ` Ted Dennison
2001-11-02 14:38 ` Preben Randhol
2001-11-02 15:15 ` Larry Kilgallen
2001-11-02 4:35 ` Eric Merritt
2001-11-02 15:46 ` Ted Dennison
2001-11-02 7:28 ` Ehud Lamm
2001-11-02 14:57 ` Marin David Condic
2001-11-02 15:57 ` Francisco Javier Loma Daza
2001-11-02 16:28 ` Marin David Condic
2001-11-02 17:08 ` Ted Dennison
2001-11-02 15:06 ` Ted Dennison [this message]
2001-11-02 15:32 ` Marin David Condic
2001-11-02 16:33 ` Ted Dennison
2001-11-02 16:43 ` Marin David Condic
2001-11-02 22:51 ` Jeffrey Carter
2001-11-03 0:24 ` Matthew Heaney
2001-11-03 2:21 ` Jeffrey Carter
2001-11-03 22:51 ` Rosen Trick [List container strawman] Nick Roberts
2001-11-04 13:07 ` Robert Dewar
2001-11-04 17:17 ` Side-Effects in Functions [Rosen Trick] Nick Roberts
2001-11-05 2:46 ` Robert Dewar
2001-11-05 7:26 ` pete
2001-11-05 10:29 ` Dmitry A. Kazakov
2001-11-05 11:19 ` pete
2001-11-05 14:59 ` Dmitry A. Kazakov
2001-11-05 15:21 ` Preben Randhol
2001-11-05 16:04 ` Ted Dennison
2001-11-05 16:33 ` Dmitry A. Kazakov
2001-11-05 17:42 ` Warren W. Gay VE3WWG
2001-11-05 18:11 ` Preben Randhol
2001-11-06 8:38 ` Dmitry A. Kazakov
2001-11-06 9:31 ` tgingold
2001-11-06 0:10 ` Nick Roberts
2001-11-06 9:30 ` Dmitry A. Kazakov
2001-11-06 16:18 ` Lazy Evaluation [Side-Effects in Functions] Nick Roberts
2001-11-07 3:42 ` Robert Dewar
2001-11-07 4:42 ` Darren New
2001-11-07 11:54 ` Robert Dewar
2001-11-07 13:32 ` Florian Weimer
2001-11-07 13:24 ` Jean-Marc Bourguet
2001-11-09 18:06 ` Ted Dennison
2001-11-09 18:27 ` M. A. Alves
2001-11-11 20:13 ` Georg Bauhaus
2001-12-06 17:47 ` Harri J Haataja
2001-11-07 9:28 ` Dmitry A. Kazakov
2001-11-06 20:08 ` Side-Effects in Functions [Rosen Trick] Florian Weimer
2001-11-06 22:48 ` Nick Roberts
2001-11-07 10:46 ` Florian Weimer
2001-11-05 13:56 ` Robert Dewar
2001-11-05 16:08 ` Ted Dennison
2001-11-05 17:44 ` Warren W. Gay VE3WWG
2001-11-05 15:56 ` Ted Dennison
2001-11-05 18:46 ` Nick Roberts
2001-11-08 11:51 ` Georg Bauhaus
2001-11-16 0:31 ` List container strawman Vincent Marciante
2001-11-05 15:10 ` Marin David Condic
2001-11-05 18:31 ` Ted Dennison
2001-11-05 19:09 ` Marin David Condic
2001-11-05 21:23 ` Ted Dennison
2001-11-07 19:27 ` Stephen Leake
2001-11-02 18:11 ` Mark Johnson
2001-11-02 18:46 ` Marin David Condic
2001-11-02 19:21 ` Larry Kilgallen
2001-11-03 22:30 ` Nick Roberts
2001-11-02 16:26 ` Ted Dennison
2001-11-02 16:36 ` Marin David Condic
2001-11-02 19:31 ` Ted Dennison
2001-11-02 17:49 ` Jeffrey Carter
2001-11-08 10:34 ` Ehud Lamm
2001-11-08 18:53 ` Better Finalisation [List container strawman] Nick Roberts
2001-11-09 13:36 ` Robert Dewar
2001-11-09 15:04 ` Florian Weimer
2001-11-10 0:36 ` Nick Roberts
2001-11-09 15:16 ` Ted Dennison
2001-11-09 17:30 ` Better control of assignment Jeffrey Carter
2001-11-10 0:32 ` Nick Roberts
2001-11-10 22:27 ` Jeffrey Carter
2001-11-13 6:36 ` Craig Carey
2001-11-13 6:39 ` Craig Carey
2001-11-13 8:53 ` Craig Carey
2001-11-14 9:42 ` Craig Carey
2001-11-09 14:49 ` List container strawman Ted Dennison
2001-11-09 16:12 ` Ehud Lamm
2001-11-09 17:12 ` Marin David Condic
2001-11-09 18:11 ` Ted Dennison
2001-11-09 18:42 ` Matthew Heaney
2001-11-10 17:54 ` Simon Wright
2001-11-02 14:49 ` Marin David Condic
2001-11-02 15:15 ` Ted Dennison
2001-11-02 15:37 ` Marin David Condic
2001-11-02 16:49 ` Ted Dennison
2001-11-02 17:09 ` Marin David Condic
2001-11-04 0:10 ` Nick Roberts
2001-11-03 23:41 ` Nick Roberts
2001-11-02 17:02 ` David Botton
2001-11-02 17:55 ` David Botton
2001-11-03 19:22 ` Nick Roberts
[not found] ` <3BE29AF4.80804@telepath.com>
2001-11-02 13:14 ` Ted Dennison
2001-11-02 13:31 ` Larry Kilgallen
2001-11-02 15:09 ` Ted Dennison
2001-11-02 15:13 ` Preben Randhol
2001-11-02 20:48 ` David Starner
2001-11-02 22:49 ` Larry Kilgallen
2001-11-02 17:44 ` Jeffrey Carter
2001-11-02 20:07 ` Ted Dennison
2001-11-02 23:19 ` Jeffrey Carter
2001-11-03 6:56 ` Ted Dennison
2001-11-03 19:22 ` Jeffrey Carter
2001-11-04 18:58 ` Darren New
2001-11-04 19:40 ` Larry Kilgallen
2001-11-04 20:49 ` Darren New
2001-11-07 19:07 ` ramatthews
2001-11-08 0:04 ` Darren New
2001-11-08 4:50 ` Jeffrey Carter
2001-11-08 23:26 ` ramatthews
2001-11-09 18:00 ` Ted Dennison
2001-11-09 18:13 ` Jean-Marc Bourguet
2001-11-09 18:55 ` Ted Dennison
2001-11-10 1:48 ` Nick Roberts
2001-11-10 17:04 ` Ted Dennison
2001-11-10 20:59 ` Nick Roberts
2001-11-10 23:17 ` Larry Hazel
2001-11-11 3:27 ` Nick Roberts
2001-11-12 18:39 ` Darren New
2001-11-13 0:35 ` Nick Roberts
2001-11-10 19:36 ` Ehud Lamm
2001-11-10 20:15 ` Nick Roberts
2001-11-09 19:27 ` Larry Kilgallen
2001-11-09 20:03 ` Stephen Leake
2001-11-09 21:05 ` Ted Dennison
2001-11-09 22:42 ` Larry Kilgallen
2001-11-10 4:52 ` Nick Roberts
2001-11-10 20:24 ` ramatthews
2001-11-05 19:28 ` Ted Dennison
2001-11-05 19:42 ` Jean-Marc Bourguet
2001-11-05 20:40 ` Ted Dennison
2001-11-05 20:24 ` Darren New
2001-11-05 20:45 ` Ted Dennison
2001-11-05 17:21 ` List container strawman; Construct alternatives Stephen Leake
2001-11-03 7:42 ` List container strawman Simon Wright
2001-11-05 14:00 ` Stephen Leake
2001-11-08 11:17 ` Simon Wright
2001-11-13 16:29 ` Stephen Leake
2001-11-13 22:43 ` Jeffrey Carter
2001-11-13 22:48 ` Jeffrey Carter
2001-11-14 3:46 ` Nick Roberts
2001-11-15 10:23 ` Ehud Lamm
2001-11-14 14:50 ` Marin David Condic
2001-11-14 16:53 ` Jeffrey Carter
2001-11-14 17:59 ` Marin David Condic
2001-11-15 3:33 ` Nick Roberts
2001-11-15 15:10 ` Marin David Condic
2001-11-16 1:29 ` Nick Roberts
2001-11-16 16:03 ` Marin David Condic
2001-11-16 20:19 ` Nick Roberts
2001-11-15 18:08 ` Matthew Heaney
2001-11-08 14:57 ` M. A. Alves
2001-11-09 2:00 ` Jeffrey Carter
2001-11-09 18:31 ` Ted Dennison
2001-11-10 19:56 ` Ehud Lamm
-- strict thread matches above, loose matches on Subject: below --
2001-11-02 19:54 Mike Brenner
2001-11-02 21:04 ` Ted Dennison
2001-11-03 8:09 ` Simon Wright
2001-11-03 12:46 ` Simon Wright
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox