Steve Peters wrote:
On Wed, Feb 21, 2007 at 10:35:53PM -0700, Jim Cromie wrote:
+/* forward decls - minimize diff */
+STATIC SV* S_dump_op_flags(pTHX_ const OP* o);
+STATIC SV* S_dump_op_flags_private(pTHX_ const OP* o);
+static void S_dump_op_mad(pTHX_ I32 level, PerlIO *file, const OP *o);
+static void S_dump_op_rest(pTHX_ I32 level, PerlIO *file, const OP *o);
I'd rather see these done in embed.fnc than left in here.
heres the 4th patch again, with 1 less chunk, others as previously sent
and a 5th patch, which:
juggles embed.fnc entries, gathering those implemented in dump.c together
- I wanted to look for naming patterns in the routines
- the *_dump() have corresponding do_*_dump correllates, with different args
- Im not sold that this is an improvement, or even a good idea
adds this for the newly factored bits.
: this feels dirty - exposing static fns, but only in DUMP_C - why bother ?
s |SV* |dump_op_flags |const OP* o
s |SV* |dump_op_flags_private |const OP* o
s |void |dump_op_mad |I32 level|NN PerlIO *file|NN const OP *o
s |void |dump_op_rest |I32 level|NN PerlIO *file|NN const OP *o
naming is hard - as you can see, I punted on good ones.
I must say, I don't quite see the benefit of doing this embed-ing
The new functions are purely implementation details, not shared anywhere.
For this purpose, pure C static declarations work, without needing
make regen magic, which feels to me like an action at a distance -
- make regen, embed.pl, dependencies etc..
It strikes me that embed.fnc is about controlled sharing between objects,
with conveniences like handling pTHX, making Perl_ prefix optional, etc.
For non-sharing cases, we dont need all the extra mechanism,
and could / should use plain vanilla static.
But Im just thinking out loud.