On 01/27/2014 01:51 AM, Warren Young wrote:
On 1/26/2014 05:01, Russell Jenkins wrote:
On 26/01/2014 1:24 pm, Warren Young wrote:
Can anyone explain how the Foo module exports get changed in my trivial example?
When you 'use Dancer2', its import adds an import method into your apps namespace, overriding the one Exporter provides.
Thanks for tracking this down.
I guess this has something to do with the order Perl evaluates BEGIN blocks, since swapping the "use Dancer2" and "require Exporter" lines doesn't help.
For now, I guess the solution is to very careful to separate the Dancer-using parts of my code from the parts that get *called by* the Dancer-using parts.
You should be able to fix this over-reach on Dancer's part by using Perl's reflection features, possibly coupled with eval(). Dancer2 should be able to detect that an import() routine already exists and keep a reference to it, so it can call the overridden version if the caller passes the name of a symbol that Dancer2 doesn't export.
Why don't you roll your util functions into your customer Dancer2 plugin? This would give you access to Dancer's DSL and it will export the functions for you. Regards Racke -- Perl and Dancer Development Visit our Open Source conference on E-commerce: http://www.ecommerce-innovation.com/