Front page | perl.perl5.porters |
Postings from November 2008
On Thu, Nov 27, 2008 at 6:03 AM, Nicholas Clark <nick@ccl4.org> wrote: > 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()) > Actually, B::Generate likes to have fold_constants() and pad_alloc(). Unfortunately neither are in makedef.pl which makes B::Generate unable to compile on Win32. We do have a ticket open to add both to makedef.pl, which I was planning on taking care of shortly. Steve Peters steve@fisharerojo.orgThread Previous | Thread Next