On Thu, Nov 27, 2008 at 04:42:27PM +0000, Nicholas Clark wrote: > On Thu, Nov 27, 2008 at 12:26:51AM +0100, Vincent Pit wrote: > > > > > ... which also means that it should probably not be public, if we > > > follow the logic that the optree construction should not be public; > > > Devel::BeginLift is already copying parts of op.c to do its magic. > > > > > > > > > > But isn't the optree construction already kind of public through the > > pluggable check functions ? They can alter it by replacing ops as they > > are created. > > Um. Yes. Good point. Not sure. > Why are these pluggable? I have no idea but PL_check hackery is the basis of all my parser hacks. It's currently the only place we can get a hook into the compilation process usefully often. It's also incredible useful for doing scoped op mangling - autobox uses it for this and I have a number of other plans involving that. I would argue that PL_check mangling is not something we -should- be doing, and I don't have a problem if it breaks -provided- an alternative API is added that lets people get at op construction. Said new API could even hook -all- ops to get round the PADSV problem (which I've been shot in the face by once already :) -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Director http://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/Thread Previous | Thread Next