Front page | perl.perl5.porters |
Postings from August 2010
On Sat, Jul 31, 2010 at 11:29:13AM -0600, karl williamson wrote: > karl williamson wrote: > >Andy Dougherty wrote: > >>On Sun, 25 Jul 2010, karl williamson wrote: > >>Right now, this is the only thing that will work. Functions intended > >>to be "inline" have to be in the same compilation unit. Making a > >>private header, such as foo_inline.h, is one way to do that. That approach appeals to me. It avoids polluting external namespaces with (even) more functions. > >I made it an external function in 5.12.0 only because of the need for it > >in re_comp.c. The API was deliberately not exposed. It's true that > >someone could have started to use it, but I believe that we don't need > >to preserve an undocumented interface. Yes? No? > > I have since discovered that we specifically say in perlapi.pod that no > interface not documented there can be relied on. So I claim we don't > have to preserve regcurly as an external function. Yes. If it's not public, it's free to be changed. In practice, even prior to Jesse's new strict maint lockdown approach, for 5.8.x I didn't change the prototypes of any external function, public or not, because I didn't trust someone out there not to have managed somehow to expose the function named mangled with the arguments in some way that dynamic linking would fail (at run time, probably even lazily) if the arguments changed, *and* that they'd then blame *me* for their problem. Fools seem to consistently out-innovate the people making things fool-proof. Nicholas ClarkThread Previous | Thread Next