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:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
