Re: TLV to memPools

Adrian Chadd wrote:

> Maybe. I don't like "hiding" the data in the way its done with cbdata.
> Perhaps if things are modified one system at a time, and a void *is used
> for the callbacks the changes won't need to be as sweeping?

For cbdata it makes sense to hide all details. These are typed
allocations where the even the type is hidden to 50% of the users (the
ones doing callbacks). Maintaining integrity would be hard if cbdata did
not hide the details.

For MemBuf as well as it adapts dynamically to what you put in the
buffer. What is relevant to the user is the size of the data put into
the MemBuf, not the size of the buffer MemBuf uses to store the data.
Simlar argument applies to String.

My gut feeling is that in most cases where we send data with a free
function it should have been implemented as reference counted data. I
don't see it viable that all pointers need to be seen as triples of
"pointer, freefunction, some argument to the freefunction". Now, it
isn't that many occations where we use a free function these days. The
only ones I know of is I/O functions, and there is should not be needed
as we should have a standardized type for I/O data.

If you send data to a function the function should know what data it
accepts, and we should hanve a single policy on how to manage such data.

If you send a reference use in a callback then cbdata should be used,
and the function should not care about what the actual data is other
than that it is cbdata compatible.

Regards
Henrik
Received on Tue Oct 09 2001 - 03:22:57 MDT