RE: [PEAR-DEV] DB_Light
| From: | Jason Lotito | Date: | Tue, 04 Dec 2001 19:54:04 +0000 |
| Subject: | RE: [PEAR-DEV] DB_Light | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-3376@lists.php.net to get a copy of this message | ||
> > Well, that would defeat the purpose of loading as little code as
> > possible, because to give the user the choice would not
> only force you
> > to load that code, but force you to parse what they want,
> which would
> > slow things down.
>
> Aehm, I was saying that the code should only be included when
> needed via some magical php construct. This would require a
> little bit of code that would load the added functionality.
>
> 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.
>
> But I fear it will end up similar to how you suggest because
> I can't come up with that magical php construct I am dreaming off.
>
> Lukas Smith
> smith@dybnet.de
This seems to be a rather 'KLUDGE' or 'hackish' type idea, but it might
get some ideas rolling.
In calling the features, obviously something like this would come along:
$dbconn->unloadedFeature($sql);
However, if it's not a method of the object, you get an error from PHP.
Using set_error_handler(), you can capture that error, and parse it, I
believe, and from that error string, we can tell if we need to include
another file based on what function the person was trying to use.
This is all theory of course, and seems rather hackish. However, it was
a sudden thought and felt compelled to at least offer it up.
Jason Lotito
jason@lehighweb.com
www.NewbieNetwork.net