Re: Re: New PHP extension

<brianm@dealnews.com> wrote : > | Hehe, totally true, but I really wonder why something like this is > | necessary at all... do you have a good example to enlighten me? > | > | Derick > > Hmmm, an example. I assume you mean an example where I "need" it? I can't > prove I "need" it. The reason we want it is situations where code is > included inside of functions. Here is some code: > > file1.php > =========== > <?php > > include_once "$CODELIB/url_conversion.php"; > include_once "$CODELIB/other_stuff.php"; > > > // assume this file has 15 functions in it > > > ?> > > file2.php > ========== > <?php > > // this file is included on our front page. > // do_stuff is only called 1/100 times > > function do_stuff() > { > // include this here to keep from parsing it all the time. > include_once "$CODELIB/file1.php"; > call_function_from_file1(); > } > > // other functions. > > ?> > > In the above example, we have two files that are in our code library. Here > at dealnews, we have 500+ files in our library that we have written over the > last 5 years of writing PHP. Our prepend defines the variable $CODELIB. It > is the path to our code library. our front page includes file2.php for > various reasons. On average, every 100 pages have to call the do_stuff > function. The do_stuff function uses a function in file1.php. To keep from > having to parse file1.php on every page, we include it in the function. > > Now, having $CODELIB be a super global allows us two luxuries in this case. > 1) When we include file1.php, we don't have to use the global keyword which > makes a reference and is slower than our second option copying the variable. > Also, we don't have to use the $GLOBALS array which makes working with > strings harder and increases our code complexity. 2) We don't have to worry > about what variables are used in the includes at the top of file1.php. As > you can see, it unconditionally includes two files. We have 5-6 more > variables defined in our prepend like this. > > Now, while you may find our code layout and usage to be wrong, remember, I > am submitting this as a PECL extension, which is totally optional for people > to install and use. I am not proposing this be a part of the PHP core, > which IMO, would be a mistake. > > Whether this is put in PECL or not, we will continue to use it. I think this is a risky extension, I don't like the idea of messing with super globals. Of course, this is PECL and people are free to use it or not but I would be scared if lots of people start to use it because there are other cleaner ways to solve this problem. This extension might cause portability or evolution problems in the future. When the only tool you have is a hammer, every problem looks like a nail. Bertrand Mansion Mamasam