Front page | perl.perl5.porters |
Postings from April 2011
On Mon, Apr 11, 2011 at 09:39:08PM +0200, Konovalov, Vadim (Vadim)** CTR ** wrote: > > From: Jan Dubois > > That patch is not acceptable. If the API is supposed to be > > available to > > CPAN modules, then it needs to be marked as a public API, needs > > documentation, and ideally also tests. (and BTW, just adding an 'X' in > > embed.fnc is *never* correct; all exported symbols should be either > > 'A', or 'EX'.) > > good. > Can you please advice whether "EX" is better - maybe I should work out better patch? > :) Ideally I'd like all the EX to go away, either because they become proper "A"s (with documented functionality, and tests for that functionality), or by changing the code that uses them to use something that is A However, I'm not sure that this ideal can be achieved totally, as there's the 're' extension, which is basically regexec.c and regcomp.c compiled with different pre-processor options, and I *think* also there are some functions which are "not public, but exist to allow a public API macro to work". > > Furthermore, there first needs to be discussion if this > > really is an API > > that should be made public in its current form in the first > > place (maybe it is, I simply don't know). > > this word - "API" - is something that will never be done, I afraid. No, not never. Working on a patch with some documentation for what store_cop_label does, and some tests for the documented functionality, would go a long way towards getting it done. Partly because trying to write tests for an API often determines whether the API is actually any good, which should clear up "is this the right design for the API?" And partly because having a ready-to-apply patch is a lot faster for someone to commit, than that person having to find time to do all the work themselves. Nicholas ClarkThread Previous | Thread Next