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