Re: DB_Light

Lukas wrote: > I could imagine some features to be in one package so if you use one > feature in that package you end up loading the entire package. Anyways I > sometimes use very basic stuff and sometimes very complex stuff. I > create my db object early on in the code and then include some modules > (not always the same) that require different levels of features. It > would be awesome if I wouldn't have to then always include the full > package. That sounds reasonable. One solution might be to have some fall though behavior when you call a method that doesn't exist in a core methods package. If I call $db->selectLimitQuery() and this method doesn't exist in a core package, then instead of throwing an error, it would be nice if I could dynamically load / instantiate that method. If you could add a method to an instantiated object dynamically (e.g.., add_method($db, "seletLimitQuery", $file_location_of_method) ) then this might work? Not sure about trapping non-existent methods though. I notice that Jason Lotito has a somewhat similiar idea and suggested that non-existant method calls might be handled by set_error_handler(). Regards, Paul Meagher