PHP4 -> PHP5 incompatibility - classes must be declared before being used

php.internals

Marc Richards

22 years ago
Hi All, I have a couple question re: {subject}. Can anybody point me to some info on why this change was neccessary (not complaining, just curious). I did some searching and it seems to relate to objects that use interfaces...but that is all I could find. If it is too complex to explain that is fine; I just want to know whether I should keep looking or not. Are there any edge cases where it would not be impossible to satisfy this requirement...say some complex interdependence between two or more classes. Sorry I know this is very hand-wavvy but I don't have enough OOP experience to come up with a good example. I read that for simple cases, instantiation before declaration will work...does/will this cause an E_STRICT error? The primary reason for my curiosity is that I recently started putting PHP functions that only get used on one page at the end of the page (and therefore calling the function before it is defined). While this greatly enhanced readibility, I was a little wary of this method, especially since I haven't really seen anybody else doing it. Is there an inherent problem with this method for functions? I guess the alternative would be to put it an included file (even though it is only included on one page). Is that what most people do? Along those lines, is there any performance penalty for using __autoload() to load my php classes if I am using a code cache like APC? Does __autoload() work for functions? Marc

Marcus Börger

22 years ago
Hello Marc, Sunday, April 11, 2004, 7:47:23 AM, you wrote:
> Hi All,
> I have a couple question re: {subject}.
> Can anybody point me to some info on why this change was neccessary (not > complaining, just curious). I did some searching and it seems to relate > to objects that use interfaces...but that is all I could find. If it is > too complex to explain that is fine; I just want to know whether I > should keep looking or not.
The new OO features of PHP 5 made that necessary. Generally if you do not use any of them (interfaces, abstract, final) the engine will (should) still be able to do everything at compile time so that you can use your classes before usage.
> Are there any edge cases where it would not be impossible to satisfy > this requirement...say some complex interdependence between two or more > classes. Sorry I know this is very hand-wavvy but I don't have enough > OOP experience to come up with a good example.
> I read that for simple cases, instantiation before declaration will > work...does/will this cause an E_STRICT error?
no but probabla something to discuss since maybe later it won't work anymore and it is 'not so good practise' or better say not recommended usage.
> The primary reason for my curiosity is that I recently started putting > PHP functions that only get used on one page at the end of the page (and > therefore calling the function before it is defined). While this > greatly enhanced readibility, I was a little wary of this method, > especially since I haven't really seen anybody else doing it. Is there > an inherent problem with this method for functions? I guess the > alternative would be to put it an included file (even though it is only > included on one page). Is that what most people do?
I guesso but includes of course come with some speed penalty.
> Along those lines, is there any performance penalty for using > __autoload() to load my php classes if I am using a code cache like APC?
Ask george
> Does __autoload() work for functions?
nope
-- Best regards, Marcus mailto:helly@php.net

Luna Kid

22 years ago
> > Does __autoload() work for functions? > > nope
But could? (Or would, some day?) Cheers, Sz.

Derick Rethans

22 years ago
On Sat, 17 Apr 2004, Luna Kid wrote:
> > > Does __autoload() work for functions? > > > > nope > > But could? (Or would, some day?)
Technically it is possible, but we ain't going to add this. Derick

Luna Kid

22 years ago
> > > > Does __autoload() work for functions? > > > > > > nope > > > > But could? (Or would, some day?) > > Technically it is possible, but we ain't going to add this.
I see, thanks. May I also ask the reasons? (I bet anyone a dead rat that *lots* of authors of simple plugin-based designs (not needing real OOP stuff) would welcome function autoloading. In fact, many of us, I'm sure, had wondered cluelessly about how to do it with __autoload, before wondering cluelessly about why was that support omitted after all...) Thanks again, Sz.

Ilya Sher

22 years ago
Luna Kid wrote: [snip]
> (I bet anyone a dead rat that *lots* of authors of simple > plugin-based designs (not needing real OOP stuff) would > welcome function autoloading. In fact, many of us, I'm sure, > had wondered cluelessly about how to do it with __autoload, > before wondering cluelessly about why was that support > omitted after all...) > > Thanks again, > Sz. >
I've actually impemented something very similar in PHP. Thereis list of funcs with the filenames they reside. (List is compacted.) The limitation if my implementation is that each func. may only have one argument so i just pass a hash and use extract().

Marc Richards

22 years ago
Marcus Boerger wrote:
>>Along those lines, is there any performance penalty for using >>__autoload() to load my php classes if I am using a code cache like APC? > > > Ask george >
Does anyone know when __autoload() gets invoked? Is it during code compilation or at runtime? Has anyone tested __autoload() with a code cache like APC or ZPS? Marc

Andi Gutmans

22 years ago
It gets called at run-time and should work with code-caches. Andi At 12:57 PM 4/18/2004 -0400, Marc Richards wrote:

Marc Richards

22 years ago
Andi Gutmans wrote:
> At 12:57 PM 4/18/2004 -0400, Marc Richards wrote: >> >> Does anyone know when __autoload() gets invoked? Is it during code >> compilation or at runtime? Has anyone tested __autoload() with a code >> cache like APC or ZPS? >> >> >> Marc >> > > > It gets called at run-time and should work with code-caches. > > Andi >
So __autoload DOESN'T get any speed enhancements for a code cache then...? Marc

Elfyn McBratney

22 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Marc, On Sunday 18 Apr 2004 17:06, Marc Richards wrote:
> Andi Gutmans wrote: > > At 12:57 PM 4/18/2004 -0400, Marc Richards wrote: > >> Does anyone know when __autoload() gets invoked? Is it during code > >> compilation or at runtime? Has anyone tested __autoload() with a code > >> cache like APC or ZPS? > >> > >> > >> Marc > >> > > It gets called at run-time and should work with code-caches. > > > > Andi > > So __autoload DOESN'T get any speed enhancements for a code cache then...?
Why do you think that? When it comes down to basics, it's caching opcodes that gives the performance boost (I don't know about APC and ZPS, maybe there are other performance enhancing algorithms in those products). And in the case of Turck MMCache (the one I use :) it's just another cached script. In the end, __autoload() is just another userland function (with magic powers ;) Elfyn - -- Elfyn McBratney, EMCB mailto:elfyn@emcb.co.uk http://www.emcb.co.uk/ PGP Key ID: 0x456548B4 PGP Key Fingerprint: 29D5 91BB 8748 7CC9 650F 31FE 6888 0C2A 4565 48B4 Error: quote_machine(): Dry humour detected.
>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ <<
<< ~ Linux london 2.6.5-emcb-241 #2 i686 GNU/Linux ~ >>
>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ <<
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAgsXJaIgMKkVlSLQRAt/xAJ9MttEjReBiVWJURPUuQNNdPQXrywCgnbKG ZWK/o4JtuZ6aAxuBe3YfEC0= =SAEU -----END PGP SIGNATURE-----

Andi Gutmans

22 years ago
At 01:06 PM 4/18/2004 -0400, Marc Richards wrote:
>Andi Gutmans wrote: > >>At 12:57 PM 4/18/2004 -0400, Marc Richards wrote: >>> >>>Does anyone know when __autoload() gets invoked? Is it during code >>>compilation or at runtime? Has anyone tested __autoload() with a code >>>cache like APC or ZPS? >>> >>> >>>Marc > > > > It gets called at run-time and should work with code-caches. > > > > Andi > > > > >So __autoload DOESN'T get any speed enhancements for a code cache then...?
Yes it should. Andi

Marc Richards

22 years ago
Andi Gutmans wrote:
> At 01:06 PM 4/18/2004 -0400, Marc Richards wrote: > >> Andi Gutmans wrote: >> >>> At 12:57 PM 4/18/2004 -0400, Marc Richards wrote: >>> >>>> >>>> Does anyone know when __autoload() gets invoked? Is it during code >>>> compilation or at runtime? Has anyone tested __autoload() with a >>>> code cache like APC or ZPS? >>>> >>>> >>>> Marc >> >> > >> > It gets called at run-time and should work with code-caches. >> > >> > Andi >> > >> >> >> So __autoload DOESN'T get any speed enhancements for a code cache >> then...? > > > Yes it should. > > Andi
Ok so either I am confused or I am not being very clear with my questions. Let me try to be as explicit as possible. Do the pages that get included by the __autoload() function get parsed and compiled along with the original page when using a code cache? I assumed that since __autoload gets called at runtime, it would be too late for the caches to do their parsing, optimizing and caching. On the other hand I was under the impression that include()d files get pulled in at compile time and therefore get parsed and cached. Maybe I am confusing the meaning of runtime and compile time, but hopefully I have been clear enough that the source of my confusion will be obvious. Marc

George Schlossnagle

22 years ago
On Apr 18, 2004, at 2:24 PM, Marc Richards wrote:
> Do the pages that get included by the __autoload() function get parsed > and compiled along with the original page when using a code cache?
No, but since all the code caches cache each include file independently, it doesn't matter. The include (assuming that your __autoload() does an include) will happen, the file will get cached, etc.
> > I assumed that since __autoload gets called at runtime, it would be > too late for the caches to do their parsing, optimizing and caching. > > On the other hand I was under the impression that include()d files get > pulled in at compile time and therefore get parsed and cached.
The whole point of a compiler cache is that files are included many many times. The compiler cache trys to avoid the compilation on every request after the first. ZE mixes compile and execution stages pretty fluidly (for example, an 'include' is compiled when it's statement is hit during runtime), so the time that __autoload() gets called is pretty orthogonal to a compiler cache's ability to cache things. The things a compiler cache doesn't speed up are eval()'s, because the code to be compiled is dynamic. George

Marc Richards

22 years ago
George Schlossnagle wrote:
> > On Apr 18, 2004, at 2:24 PM, Marc Richards wrote: > >> Do the pages that get included by the __autoload() function get parsed >> and compiled along with the original page when using a code cache? > > > No, but since all the code caches cache each include file independently, > it doesn't matter. The include (assuming that your __autoload() does an > include) will happen, the file will get cached, etc. > > > >> >> I assumed that since __autoload gets called at runtime, it would be >> too late for the caches to do their parsing, optimizing and caching. >> >> On the other hand I was under the impression that include()d files get >> pulled in at compile time and therefore get parsed and cached. > > > The whole point of a compiler cache is that files are included many many > times. The compiler cache trys to avoid the compilation on every request > after the first. ZE mixes compile and execution stages pretty fluidly > (for example, an 'include' is compiled when it's statement is hit during > runtime), so the time that __autoload() gets called is pretty orthogonal > to a compiler cache's ability to cache things. The things a compiler > cache doesn't speed up are eval()'s, because the code to be compiled is > dynamic. > > George
Ahh. That clears it up. Thanks George. Marc

Andi Gutmans

22 years ago
include()'s are also done at run-time and autoload is very similar, thus, YES code caches will work with it. Please don't ask this question again :) At 02:24 PM 4/18/2004 -0400, Marc Richards wrote:

Friedhelm Betz

22 years ago
On Sunday 11 April 2004 23:16, Marcus Boerger wrote:
> Hello Marc,
[...]
> > > > I read that for simple cases, instantiation before declaration will > > work...does/will this cause an E_STRICT error? > > no but probabla something to discuss since maybe later it won't work > anymore and it is 'not so good practise' or better say not > recommended usage. >
I really like it would produce an E_STRICT error, see http://bugs.php.net/bug.php?id=27440 Regards Friedhelm