apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Skiplist duplicates
Date Thu, 12 Mar 2015 22:23:00 GMT
On Thu, 12 Mar 2015 13:36:55 -0400
Jim Jagielski <jim@jaguNET.com> wrote:

> > 
> > No, it's a design error.  There's not much helping that... once it
> > ships, that's our implementation.  Might caution us to provide more
> > careful code review before n.n.0 releases on new features.
> Soooo.... if apr_snprintf("%d" were to, on every 50th int, print
> it out in decimal form, that would be a "design error"? :)

No, because %d's behavior is documented, and you are citing a bug that
is in violation of that behavior.

> If so, how can we call it a "skiplist" which has a set of compliant
> expectations? It's not a skiplist implementation at all since it
> is broken.

But a user is only going to know whether they are loading against a
valid libapr-1.so if there is a new entry point in 1.6.0 that reflects
the (to your phrase) not-broken behavior.  Otherwise the entire tower
is built on sand.

This is a multi-project, multi-consumer library, not an httpd sandbox.
There are expectations and we have to meet them, and these are all
very well spelled out in the versioning docs for this project.

Using list/tree functions to identify dups is a very well understood
design pattern.  Therefore it is a surprise if you claim 'oh, but was
meant to allow dups' when it was neither documented to allow dups, nor 
actually allowed them.

Any structure, btree, hash, linked list, can be designed to allow or
to deny dups, either as a choice of the add function, or an intrinsic
design element that refuses a belief in dups.  It seems Yann is already
on to the appropriate solution, so let's go with that and not revisit
the entire versioning rules of the project during the 1.x lifespan.

View raw message