httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: Portability of APR.
Date Wed, 15 Sep 1999 14:17:50 GMT
On Wed, 15 Sep 1999, Dave Jones wrote:

> I can't find any sources defining this ap_get_file_length() function, the
> only interface I see to return the file size is to call ap_getfileinfo()
> and pry into the ap_file_t struct to get the size field.
> 

Then it was never written.  I haven't needed it so far.  When it is
needed, it will get written.  It is not possible to "pry" into the
ap_file_t structure.  All of these types were written as incomplete types
to keep people from writing non-portable code with them.  By pry'ing into
the type, your code is automatically unportable, because I cannot and will
not garauntee that all platforms have the same fields in the types.

> It's not a question of what you'd do, it's a question of imprecise
> specifications that let future developers/maintainers get themselves into
> trouble.

I may be wrong, but it is a question of what we would do.  If you
implement something, and provide a diff to be committed, and I would
rather do it a different way, then we have a discussion before it gets
committed.  Same way that when I do something that Ben doesn't like, he
lets me know, and we discuss it.  It then gets changed, assuming we both
agree he is right in the end, as soon as I can change it.  The perfect
example of this, is the order of arguments.  I did it wrong.  It's not
intuitive.  So, I will be taking next week, and I will begin to change
this.

If the specs aren't exactly precise or complete, it is because I don't
know everything, and rather than pretend I do, I am leaving it open for
other people to suggest ways to do things.  I don't even know where all of
the imprecise-ness is.  When you pointed out a problem, I gave three
suggestions.  You followed up with a fourth.  Your solution is the better
solution.  When somebody gets around to implementing it and providing a
patch, it will get into the code.  That's the way the Apache Group works
as near as I can tell.  If I am wrong, somebody tell me.

> Code frequently outlives the active interest of the original programmer
> and gets picked by others who just as frequently ignore or misread the
> original programmer's assumptions.    My suggestion about the ap_get_os
> functions was simply to make it as hard as possible for platform-specific
> code to compile on platforms the original programmer did not anticipate.

I don't want to make it hard for platform specific code to work on
platforms that weren't originally intended.  Because, if a programmer is
smart, s/he can make code the current code portable.  But, they don't HAVE
to.  I am afraid that with different functions for different platforms,
the code CAN'T be made portable at all.  That is an insult to the
programmers who have to use those calls, because it doesn't give them a
chance to be creative.  IMHO, your solution ties other programmer's hands,
where as mine allows them to solve an interesting problem in the best way
they can.  However, as near as I can tell, neither of us has plans to use
these functions.  So perhaps the best thing to do, is to leave the
question for somebody who does.

Anybody working on php or mod_perl, if somebody is listening, I suspect
that these two modules will be the biggest users of these functions.  Do
you have an opinion of the best way to implement them?  One function for
each platform, or one function for all platforms?

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message