abstraction speed considerations

I've been thinking about the slow-down issue with the new abstraction again. I think that a good portion of it is caused by the indirect calls via core__execute_core_function. Now, instead of making a direct function call, there is a call to _execute_core_function which: 1) does the dynamic require, 2) a string concatenation and finally 3) a dynamic function call on the core object. In fact, the purpose of the indirect call here is not caused by the fact that we don't know what function to call at code time but instead so that the plugin can be autoloaded (saving the need to have to type require_once prior to using the function call). It seems to me that the point of a core function is that it is necessary for the core operation--meaning it shouldn't be loaded on demand, but simply available. If it *is* to be loaded on demand, any function that uses a plugin style core ought to do a require_once for that function. That way, Smarty can return to using direct calls for core functions and eliminate the need for core_execute while at the same time, only load plugin functions that actually get used. Besides being faster than core_execute, IMHO, the indirect calls make the codebase a bit awkward. It is especially noticable since they aren't being used to dynamically call functions (which would be an appropriate use) but instead, to dynamically load code for static functions names (which I think is an inappropriate use). Just my 2c. xo boots __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com