Front page | perl.perl5.porters |
Postings from November 2008
On Wed, Nov 26, 2008 at 09:30:43PM +0000, Nicholas Clark wrote: > 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) Although it does use fold_constants() and op_clear(), which are not public. I'd already purged the former to be static. (So in theory it breaks, but in practice there isn't a regression test in B::Generate that check this) And I was about to purge the latter. Except then it comes back to: > 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? And it's sort of looking like fold_constants() and op_clear() are useful and well defined. (Um, also like peep() and linklist()) Nicholas ClarkThread Previous | Thread Next