Re: Compressed text-base patch

On Mon, 2003-04-28 at 19:18, rbb@rkbloom.net wrote:
> > How many data structures do this
> > besides apr_file_t? Is this behavior desired, or would you rather have
> > the data associated with the actual object?

> They all do it.

I think he meant "how many data structures would you really have to add
hash tables to in order to get the other behavior? (The answer appears
to be four: file, socket, thread, threadkey.)

> The userdata stuff is an aspect of pools, not of the APR
> types themselves. This is the desired behavior.

I'm with Eric and Phillip; the current behavior is counterintuitive and
dumb. (And poorly documented.) If userdata is going to be an aspect of
pools and nothing else, then all the other *_data_{get,set} functions
should be deprecated.

> It makes no sense at all for every APR type to implement the userdata
> functions themselves.

It may not be your preference, but it certainly makes a kind of sense.

> The pools implement userdata, and all other types get it for free.

Currently, they don't get it for free; they get it at the cost of
defining a function which passes on the responsibility to the pool.
They could just as easily pass on the reponsibility to a hash table, so
the implementation cost is identical. There would be a one-pointer
space penalty associated with keying the data to the objects themselves;
that's a tiny cost given the heavyweight nature of files, sockets, and
threads.

> However, if you really want my opinion, the user_data stuff in APR was
> never fully thought out.

Here I agree with you, actually. Object user data is a bit like global
variables. You often feel like they're exactly what you want, but after
you start using them, you later realize that your function contracts are
totally undefined and your program isn't nearly as maintainable as if
you had designed without them.

So, I'm -0 on any new uses of user data in svn.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 29 01:39:18 2003