Hi, as you perhaps know I have recently added APR::Socket->fileno. But on Windows this function doesn't do anything useful.
Later I have added the C<#_if_ ...> mini language to ModPerl::MapUtil, see http://svn.apache.org/viewvc?rev=940287&view=rev The latter was caused to make modules like ModPerl::Interpreter possible that make sense only if perl has been compiled to support multiple interpreters. See http://svn.apache.org/viewvc/perl/modperl/branches/threading/xs/maps/modperl_structures.map?rev=940297&r1=940296&r2=940297&view=diff http://svn.apache.org/viewvc/perl/modperl/branches/threading/xs/maps/modperl_types.map?rev=940297&r1=940296&r2=940297&view=diff Now I think in cases like APR::Socket->fileno it might be better to leave it unimplemented when it cannot do anything useful. That would mean the user would see something like this in the error_log: [Sat May 08 14:19:39 2010] [error] [client 127.0.0.1] Can't locate object method "fileno" via package "APR::Socket" at /home/r2/work/mp2/trunk/clean- trunk-prefork/t/response/TestAPR/socket.pm line 43.\n Now the user of a module that uses something that is not implemented under certain conditions can ask the author what that means instead of silently wondering what he did wrong. My question in general is * is it better to implement something like C<< return -1 if $^O eq 'win32'; do_the_real_stuff >> * or leave it conditionally unimplemented like this: Index: xs/maps/apr_functions.map =================================================================== ... +#_if_ $^O ne 'linux' mpxs_APR__Socket_fileno | | apr_socket_t *:socket +#_end_ ... +#_if_ $^O ne 'linux' ~apr_os_sock_get +#_else_ +-apr_os_sock_get +#_end_ ... Comments? Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
