On Mon, Jan 01, 2001 at 08:40:26PM -0800, [EMAIL PROTECTED] 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/
