Front page | perl.perl5.porters |
Postings from November 2008
On Wed, Nov 26, 2008 at 04:10:58PM +0000, Nicholas Clark wrote: > On Wed, Nov 26, 2008 at 04:36:34PM +0100, Rafael Garcia-Suarez wrote: > > 2008/11/26 Nicholas Clark <nick@ccl4.org>: > > > Do we want to make that policy decision? That optree construction is private. > > > > If it's not private, it's public somehow. I merely want to assert that > > we don't support the internal API that is used to construct and > > optimise optrees. Perl_peep() is not public either, for example. Those > > are functions that do more than optree inspection. > > To my mind the most logical way to assert that we don't support something is > to make it static whenever we can. So I made the appended change. > (And then went looking for other non-public non-static functions that the > core does not need outside the file of their definition) To be consistent that would mean that Perl_peep() becomes static S_peep(). Which, at least, will cause optimizer.xs to fail to link. (Although, curiously, not B::Generate) If we go all the way down the road of "the API used to construct and optimise optrees is internal" then we preclude certain potentially useful modules appearing on CPAN. So should we provide some level of API? If so, what? Nicholas ClarkThread Previous | Thread Next