On Tue, 19 Apr 2005, Stas Bekman wrote: > Randy Kobes wrote: [ ... ] > > I most likely don't appreciate the implications of your > > comment about exposing the API that may trigger a particular > > error - if we supply an APR::Const::EFOOBAR, then is there > > any added maintenance burden in also supplying an > > APR_STATUS_IS_EFOOBAR(s) macro? > > That's not what I've said or meant to say. I say that we > certainly *should not* provide error codes/macros for APIs > that we don't expose. And in reverse we *should provide* > error codes/macros for APIs that we do expose. Though > I've suggested that unless someone wants to review what > error macros are required, we start with what we know we > need. > > Re: APR::Const::EFOOBAR vs. APR_STATUS_IS_EFOOBAR(s), it's > a tricky situation. If both are exposed how does the user > know which one they need to use? e.g. in the case of > EAGAIN you can see that a developer working on unix can > use just APR::Const::EAGAIN, so it won't work on win32, so > APR_STATUS_IS_EAGAIN needs to be used. So may be we need > to abolish the constant APR::Const::EAGAIN to make sure > users use APR_STATUS_IS_EAGAIN. But may be someone needs > to check whether the error code is a real EAGAIN and not > something else, in which case the will want to use > APR::Const::EAGAIN. Therefore I suppose you are right, we > should expose both, and make sure that the documentation > uses the IS_ version and the API doc for > APR::Const::EAGAIN states that it's not cross-platform and > point to APR::Status::is_EAGAIN
Thanks for the elaboration - that sounds like a good idea to start with what we know we need (EAGAIN), and then add ones later if the need arises. > > I know some of the constants > > (defines) in apr_errno.h that arise in the composites (eg, > > SOCEWOULDBLOCK in APR_STATUS_IS_EAGAIN) aren't supplied by > > APR::Const, but that should be taken care of at the C level. > > right > > > On the other hand, simplicity is a virtue - if we wanted to > > start just with IS_EAGAIN, then that's fine; it's certainly > > easy to add others as the need arises. > > :) > > BTW, re: my previous comment about the name case. May be > APR::Status::is_EAGAIN is better than > APR::Status::IS_EAGAIN? So by using lowercase is_ we show > that it's a function, but by using upcase EAGAIN we better > match the error code? APR::Status::is_EAGAIN sounds good ... I'll make up a modified patch doing this, defined as a macro, for just EAGAIN. -- best regards, randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
