apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr/include apr_general.h
Date Tue, 02 Jan 2001 05:31:04 GMT
On Mon, Jan 01, 2001 at 08:40:26PM -0800, rbb@covalent.net wrote:
>...
> > Heh. It's documented only cuz you put it in there today :-) Kind of like
> > saying, "well, I can write ugly code because I just updated the design
> > document to allow me to."
> > 
> > Just because you documented it, doesn't make it any safer.
> 
> Actually, it's documented today, because I wrote the docs today, I believe
> this was mentioned in an e-mail a LONG time ago, when I first designed APR
> and decided to implement it with incomplete types.  It's been this
> way from the beginning however.  There has never been an APR incomplete
> type that didn't begin with a pool.

The design was to include a pool in the (incomplete) type. There was never
anything about "it must be at the beginning." That's just where it got
dumped.

But the point is moot. I was merely expressing amusement at the
justification of "its in the docs."

> > It is a non-typesafe hack.
> > 
> > We've spent quite a bit of time trying to increase type safety. Look at the
> > original hooks, the new hooks from Ben, the macros for the directives, etc.
> 
> Yes, and those things could be implemented with type-safeness, without
> affecting the amount of duplicated code, or maintainability.

If that is your impression of the hooks, then I can give you a similar pair
of macros for the incomplete types.

APR_DECLARE_POOL_ACCESSOR(file)
APR_IMPLEMENT_POOL_ACCESSOR(file)

or somesuch. Since I'm the one with the issue on type safety, I'd be quite
happy to do this work.

> Creating 12
> different functions (one per APR type) to get access to the pool, which is
> garaunteed to be in the same place in each structure.  This is just adding
> code that we need to maintain.  Granted, they are easy functions, but why
> do we need or want 12 of them?  Plus, it is just gets more complex as we
> add more types.

Nah. These are brain-dead, zero-maintenance functions. There is no
complexity or mental overhead with them.

>...
> > > We control the type
> > > definitions, and we control the macro.  This is very similar to what Dean
> > > did with the ap_iol code.
> > 
> > 1) because it has been done before doesn't make it right
> > 2) looking at ap_iol.h, I don't see what you are referring to. where did
> >    this casting stuff occur?
> 
> There are three types, ap_iol, iol_socket, and iol_file.  iol_socket and
> iol_file are two types that rely on the fact that the first field in their
> structures was an ap_iol.  Basically, you pass an ap_iol into any of the
> underlying functions, and it gets cast into the correct type.  From there,

Ah. That's why I didn't see what you were getting at. That situation is a
"subclassing" scheme. Each subclass does the cast to access its data. That
is still type-unsafe, but the casting occurs within the implementation in
limited circumstances (rather than clients doing casts).

>...
> > Ryan: this is really not a good idea because of the type safety stuff.
> > Please use accessor functions instead.
> 
> I completely disagree.  This is a perfectly valid C operation.  I have

It is valid, but I am saying that we should not use that technique for APR.
I'm asking you to back out the change and use a different approach. As I
mentioned, I am also willing to do the work.

>...
> If I understand your problem with this, you are afraid that somebody will
> use this macro on a variable that is either not an APR variable, or is an
> APR type but is not one of the incomplete types.

I'm also worried about future work when the pool gets moved for some reason,
or a new type is introduced without a pool, or it is introduced and the pool
isn't at the beginning.

All of the above situations are concerning me, and are easily avoided with
accessor (typesafe) functions.

>...
> We
> do not need to protect programmers from themselves in all cases.

I agree with the general sentiment, but this pattern passes my threshold :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message