Fundamental design flaws
Tom Lord
(29 Oct 2003 17:46 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(29 Oct 2003 19:13 UTC)
|
Re: Fundamental design flaws
Bradd W. Szonye
(29 Oct 2003 20:06 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(29 Oct 2003 20:47 UTC)
|
Re: Fundamental design flaws
Tom Lord
(29 Oct 2003 23:24 UTC)
|
Re: Fundamental design flaws
Taylor Campbell
(30 Oct 2003 01:53 UTC)
|
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 04:42 UTC)
|
Re: Fundamental design flaws
Tom Lord
(30 Oct 2003 16:52 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 17:11 UTC)
|
Re: Fundamental design flaws
Tom Lord
(30 Oct 2003 16:33 UTC)
|
RE: Fundamental design flaws
Anton van Straaten
(30 Oct 2003 16:52 UTC)
|
Re: Fundamental design flaws
Bradd W. Szonye
(30 Oct 2003 17:19 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 18:13 UTC)
|
Re: Fundamental design flaws
Bradd W. Szonye
(30 Oct 2003 21:18 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 21:26 UTC)
|
Re: Fundamental design flaws
Bradd W. Szonye
(30 Oct 2003 21:35 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 21:49 UTC)
|
Re: Fundamental design flaws
Bradd W. Szonye
(30 Oct 2003 21:55 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 22:05 UTC)
|
Re: Fundamental design flaws
Bradd W. Szonye
(30 Oct 2003 22:28 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 22:52 UTC)
|
Re: Fundamental design flaws
Alex Shinn
(31 Oct 2003 03:04 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(31 Oct 2003 03:20 UTC)
|
Re: Fundamental design flaws
Alex Shinn
(31 Oct 2003 07:13 UTC)
|
RE: Fundamental design flaws
Anton van Straaten
(30 Oct 2003 23:07 UTC)
|
Re: Fundamental design flaws
Bradd W. Szonye
(31 Oct 2003 03:12 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 21:57 UTC)
|
Re: Fundamental design flaws
Tom Lord
(30 Oct 2003 20:23 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 20:35 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 17:06 UTC)
|
Re: Fundamental design flaws
Bradd W. Szonye
(30 Oct 2003 17:26 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 18:15 UTC)
|
Re: Fundamental design flaws
bear
(30 Oct 2003 18:48 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 19:35 UTC)
|
Re: Fundamental design flaws
bear
(30 Oct 2003 19:45 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 20:08 UTC)
|
Re: Fundamental design flaws
bear
(30 Oct 2003 20:40 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 20:48 UTC)
|
Re: Fundamental design flaws
Tom Lord
(30 Oct 2003 20:49 UTC)
|
Re: Fundamental design flaws
scgmille@xxxxxx
(30 Oct 2003 21:02 UTC)
|
Re: Fundamental design flaws
Bradd W. Szonye
(30 Oct 2003 21:26 UTC)
|
> > example rather than BAG-CONTQ?, BAG-CONTV?, BAG-CONTAINS? (and, > > perhaps BAG-CONTAINS=? to permit an arbitrary predicate). > > > > For something like a hash table, sure -- at creation time I really > > need to establish what notion of equality (and hence, hashing) is in > > play -- but for bags? > > OK. This point I concede. I don't like the handling of equality > functions either. I'd probably prefer optional comparison arguments > to many of the procedures, but I'd have to talk with Scott and > Matthias about this before becoming certain that that would be better. I can see both sides here, but let me state the other side that you may not be considering. There may be bags whose internal representation is dependent on the equivalence function in the same way that its important for hash table based dictionaries. A bucket based bag, for example, may need the equivalence function to classify the values it stores, allowing it to have logarithmic performance for contains? because it has pre-sorted its values in a certain way. This is the rationale for pre-specification of the equivalence function. If all bags were completely unorganized collections of values and all had guaranteed O(N) lookup times, then it would be just fine to pass the equivalence function at call time. Scott