Luis, for my sake could you elaborate on the provider pattern and how it is defined. I spent about half an hour googling on it, and the only references I can find on the Internet all appear to be talking about a .NET specific pattern of that name.
I guess either way, I’d have to ask if our goal is to implement a specific pattern or solve a problem. (I’m being devils advocate here for a minute
If allowing the provider to also become a proxy “breaks” the pattern, then we could simply stop calling that as long as our finished product is clean and useful. I’m not sure if breaking out a separate functionality for the sake of keeping the original pattern pure accomplishes anything other than fragmented implementation.
Anyway, the above sounds a little snarky, but I promise I don’t mean it that way. I love patterns and the philosophy behind them so I’m just trying to candidly ask some questions while hoping to learn a bit of theory on the matter.
I really appreciate your comments! The initial driving force behind providers where to basically just provide you the object. I guess adding an onMissingMethod to it to proxy the methods of the provided object could also be an enhancement to the providers. I guess semantically speaking, then the providers become also proxy’s to the original object. So that is why I am hesitant on it, but let’s create an enhancement ticket for it.
That;s an interesting idea. What about wirebox enabling you to declare decorators for ANY object?
Also, come to think of it, you can just build a listener that does this for you Brad:
component{
function configure(injector,properties){}
function afterInstanceCreation(interceptData){
var target = arguments.interceptData.target;
// Do your check if it is a provider, and if it is add proxy method.
if( isInstanceOf(‘coldbox.system.ioc.Provider’) ){
target.onMissingMethod = variables.onMissingMethod;
}
}
function onMissingMethod(MissingMethodName,MissingMethodArguments){
var results = evaluate(“get().#missingMethodName#(argumentCollection=missingMethodArguments)”);
if( NOT isNull(results) ){
return results;
}
}
}
Out of curiosity, what issue(s) do you have with oMM()?
When used properly, oMM() is a fantastic tool that I am quite in love with. Hence my curiosity.
(Of course, the key is, “when used properly”. One should not use it simply for the sake of using it, and should be judicious about when/where/how they’re using it.)
Oh, it does have some interesting implementations and can provide some great functionality, but in anything that is called a lot and is really looking for speed, I think it should be avoided.
I know it is only slight, but it is slower than a direct call to the method, so when speed counts, I try to avoid it.
