Doug MacEachern wrote: > On Sat, 29 Sep 2001, Stas Bekman wrote: > > >>I've implemented c) as it seems the most logical to me. Why? If you >>*Set* some key/val in a subsection, you don't expect to inherit some >>values for the same key from the parent section/dir. You do *Set*. >> > > i see, that makes sense. should double check what 1.x and make sure it > won't break anybody. but c) sounds correct in any case, we should > probably make 1.x do that if it doesn't already.
ap_overlay_tables (==overlay_tables) in 1.x is exactly the same as in 2.x, which means that probably nobody has used this feature, and therefore wasn't burned. >>I think apr_table needs a third constant for apr_table_overlap, since >>that's where it belongs, IMHO. > > sounds good to me. ok, so I'll commit it as is (the loop implementation), patch apr_table and see if apr folks accept my patch. If they do, I'll replace the loop with apr function. >>ok, so what's the rule of thumb of when some code should be a macro and >>when a function and when an MP_INLINEd function? >> >> From what I remember from C++ (or was it C?), you use inline when some >>code is really short, and used only a few times so you won't end up >>duplicating the same machine code a few times. >> > > that's true. in this case, modperl_table_get_set should probably not be > inline-d, it is only called once per function that uses it. we don't need > the macro form anymore since it won't be referencing ST(x) and items. > > i've been using MP_INLINE for functions that are either: > - only ever called once (the "wrappers" that are called by .xs), no matter > what the size of code is. > > - short bodies of code called in "hot" code (like modperl_env_hv_store, > which is called many times inside of a loop), where it is cleaner to see > the code in function form rather than macro with lots of \'s cool! I'm going to write the wise notes down for the next generations to learn from :) thanks for the explanations. While you are in the explanation mood, can you also explain when you decide to use a pure XS semi-XS or pure-C functions in mod_perl? From reading the code I've learned that - you use pure XS, when you need to return a value which can be of a differnt type depending on the arguments and when you need to play with stack. - you use semi-XS (PPCOde wrapper? ENTER/LEAVE scopes) when you want to take the benefit of Perl/XS wrappers. - otherwise you write in pure C. Here you've mentioned that we do that because we don't want to be depending on xsubpp. But we have already a few pure XS subs, so aren't we already depending on xsubpp? Thanks :) One last note, I want to start documenting C/XS code inlined (at least what I add and I hope gozer will help)... Do we follow some convention, like httpd-2.0 does (@param, @return...) or just whatever comes to a mind? In a few places it would save me a lot of time if I just had a short note saying how to call the function, since the nesting of macros was too deep to easily understand what it does :) I'm talking about internal stuff, which is not exposed in mod_perl API (which will be documented in pods.) also please look at my post (-2 days?) with suggested API documentation generic format, so we can start documenting things. _____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
