Front page | perl.perl5.porters |
Postings from March 2000
Horsley Tom <Tom.Horsley@ccur.com> wrote > Now, if I'm understanding all this, we are going to explicitly look > through the source for colliding names and automatically cause those > modules to be POLLUTed? > > What was the point of all this again? :-). Good point. I was proposing to look for both "PL_na" and "na" etc. If a PL... symbol was found, we can assume the module has been updated so no POLLUTE is needed. I'd only force POLLUTE if there were polluting symbols present and *no* PL... ones. So the case that would get bitten is where a module makes *no* use of Perl's external symbols, and uses symbols which are hit by pollution. So in particular, the module could never be built before 5.005 . So in practice it won't be one of the "big name" ones. Would it all be a better risk if the search was restricted to symbols which are (a) relatively common (b) although nominally polluting, extremely unlikely to clash in practice? I have in mind sv_undef sv_yes sv_no. And of course perl_destruct_level and perldb would be good risks, tho' unlikely to get any hits. I'll sit and think about this a bit more before rushing in. An interesting exercise would be to identify those modules which suffered from pollution and caused this whole exercise to be initiated. Then make sure the algorithm does the right thing for them. Does anyone remember which they were? Mike GuyThread Previous | Thread Next