Luis, an afterInstanceCreation interceptor is very creative, but unfortunately isInstanceOf() suffers from the same file system access performance that getMetadata() does. That, and I’d be deailing with the overhead off OMM (if any) as well as the overhead of the injection for each object.
Of course, the effort required has to be tempered with the benefit received, which at this point is just omitting a “.get()” from my provider.
What this does make me think of is how it seems to be bordering on the same kind of solutions we will need to implement AOP. Thinking about how to easily proxy method calls has got me thinking of all kinds of hacks from looping over public methods of the object being proxied and injecting proxy methods for each public target method to VFS proxy creation via code generation at run time. I’d love to hear more about your AOP game-plan for WireBox.
All that being said, I still think there could be a convenience benefit at best in allowing the provider to proxy methods as well. Do you still want me to put in a ticket?
And for the record, if don’t want to make that core, I would rather be allowed to subclass the provider than decorate it. Just seems cleaner than decorating a decorator.
Well, if you don’t want to use the explicit get() call from a provider then I suggest you stick to mapping the provided objects or create provider functions. With those two approaches you get the actual provided object without the get() calls.
map(“CrazyObject”).toProvider(“CrazyProvider”);
or
map(“CrazyObject”).toDSL(“provider:Crazy”);
provider function:
function getCrazy() provider=“CrazyObject”){}
That way, you just call on getCrazy() and it gives you the provided object with no need to do get()
Well, if you don’t want to use the explicit get() call from a provider then I suggest you stick to mapping the provided objects or create provider functions. With those two approaches you get the
actual provided object without the get() calls.
map(“CrazyObject”).toProvider(“CrazyProvider”);
In my case I need a provider to be injected to prevent scope widening. If I use the above and autowire model:CrazyObject the actual object that CrazyProvider provides is wired in which would defeat the purpose.
map(“CrazyObject”).toDSL(“provider:Crazy”);
If I do the above and autowire in CrazyObject then I get a provider wired in and I do actually have to call the get() method (as expected) to use it.
function getCrazy() provider=“CrazyObject”){}
I’m on CF8, and this uses getFunctionCalledName() so I can’ do that. I would love to be able to get this to work for CF8, but unfortunatley the only way I can come up with would be dynamic code generation to a temp directory, then cfincluding that temporary file at run time. Well, I guess there are other ways to get the called function name, but they all involve throwing an error and catching it which I’m not a big fan of.
So, basically I’m still stuck calling .get() on my providers.
Adrock actually has another method in there that doesn’t throw, but cffile reads the CFC in to parse out the line number of the function being executed. Not a total fan of that either though. If this info could be sufficiently cached, it would be interesting to see how affective/performant it would be to include a getFunctionCalledName() equivalent for CF8.