develooper Front page | perl.perl5.porters | Postings from November 2008

Re: Perl_linklist (was Re: modules on CPAN defining PERL_CORE)

Thread Previous | Thread Next
Rafael Garcia-Suarez
November 26, 2008 03:34
Re: Perl_linklist (was Re: modules on CPAN defining PERL_CORE)
Message ID:
2008/11/26 Nicholas Clark <>:
> On Wed, Nov 26, 2008 at 10:35:02AM +0000, Nicholas Clark wrote:
>> On Mon, Nov 24, 2008 at 04:36:01PM +0100, Rafael Garcia-Suarez wrote:
>> > 2008/11/24 Nicholas Clark <>:
>> > > 3: Perl_linklist()
>> >
>> > On one hand, this method could be made static.
>> > On the other hand, that's a nice way to walk an optree. And the interface
>> > is so simple and generic that it can survive any internal change :)
>> Well, it's essentially unchanged since revision 1, so it seems safe enough
>> to expose. What's the best way to document it? Right now, the entire
>> documentation is /* establish postfix order */

Hmm. After compilation, that only returns op_next, the next op to be
executed. During compilation, if op_next isn't set yet, it figures out
which op comes next and stores it in op_next.

> Which then makes me wonder whether any of these *should* also be declared
> public:
> p       |OP*    |sawparens      |NULLOK OP* o
> p       |OP*    |scalar         |NULLOK OP* o
> p       |OP*    |scalarkids     |NULLOK OP* o
> p       |OP*    |scalarseq      |NULLOK OP* o
> p       |OP*    |scalarvoid     |NN OP* o
> And all the rest can be made static, which may cause the trivial ones to be
> inlined. (Which isn't terrible)

sawparens is really really short. It could be made static in the hope
the compiler will inline it.

The various Perl_scalar* functions manipulate the optree being
constructed. I think they should go static too. They certainly should
not be made public.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About