Now __autoload have only one argument which is a name of searched class.
Second argument could be a namespace where class is searched. It should have
default value for backward compatibility.
What for? It always receives full name of the class, whatever it is.
I think it is the most flexible s
On Dec 22, 2007 3:43 PM, Wojciech Malota <[EMAIL PROTECTED]> wrote:
> I have a proposal for prototype of __autoload function in PHP 5.3.0.
> In this version of PHP namespaces will be available.
> Prototype of __autoload could look like this:
>
> __autoload($classname, $namespace = null);
>
> Now __
I have a proposal for prototype of __autoload function in PHP 5.3.0.
In this version of PHP namespaces will be available.
Prototype of __autoload could look like this:
__autoload($classname, $namespace = null);
Now __autoload have only one argument which is a name of searched class.
Second argume
I have a proposal for prototype of __autoload function in PHP 5.3.0.
In this version of PHP namespaces will be available.
Prototype of __autoload could look like this:
__autoload($classname, $namespace = null);
Now __autoload have only one argument which is a name of searched class.
Second argume
On Mon, 4 Apr 2005, Derick Rethans wrote:
> > FWIW, I don't think maintaining BC is super important here. I don't
> > believe lots of people are using __autoload() currently, and it should
> > be pretty trivial to migrate to whatever solution we end up with.
>
> BC is always important.
I didn't s
Alan Knowles wrote:
I dont know if you read the blog comments here:
http://www.akbkhome.com/blog.php/View/79/require_once+is+part+of+your
+documentation..html
and here
http://www.akbkhome.com/blog.php/View/77/is+__autoload+evil%3F.html
and slightly related
http://www.akbkhome.com/blog.php/View/76/r
On Sun, 3 Apr 2005, Adam Maccabee Trachtenberg wrote:
> On Sun, 3 Apr 2005, Andi Gutmans wrote:
>
> > I don't think the right solution though is to leave the not-optimal
> > solution in the engine, and create a solution outside the engine. I think
> > we should find a way to tune the engine so th
On Sun, 3 Apr 2005, Andi Gutmans wrote:
> I don't think the right solution though is to leave the not-optimal
> solution in the engine, and create a solution outside the engine. I think
> we should find a way to tune the engine so that it works well. Zeev's
> suggestion keeps BC. If there are conc
Hello Zeev,
Sunday, April 3, 2005, 10:39:39 AM, you wrote:
> At 18:31 03/04/2005, Marcus Boerger wrote:
>>Right from the beginning i said __autoload() is just wrong and we need the
>>described behavior. However all i got back is that i am just wrong and we
>>don't need it. And that from everybody
At 11:31 AM 4/3/2005 -0400, Marcus Boerger wrote:
I did not try to get it fixed i just fixed it (dot).
Right from the beginning i said __autoload() is just wrong and we need the
described behavior. However all i got back is that i am just wrong and we
don't need it. And that from everybody. But sin
Alan,
Your blog entry is actually what made me look into that topic. I'm not
sure whether I agree with you regarding the general necessity of
__autoload(). __autoload() is not only about saving the headache of
explicit require()'s, it's also about 'JITing' this task, so that no
classes are lo
At 18:31 03/04/2005, Marcus Boerger wrote:
Right from the beginning i said __autoload() is just wrong and we need the
described behavior. However all i got back is that i am just wrong and we
don't need it. And that from everybody. But since SPL already gives all
you mentioned there is no reason to
Hello Zeev,
Sunday, April 3, 2005, 6:05:22 AM, you wrote:
> All,
> One problem that became apparent after the introduction of __autoload(), is
> that different pieces of code, sometimes coming from different sources, may
> want to declare this function in a different way. Today, __autoload() is
On Apr 3, 2005, at 6:05 AM, Zeev Suraski wrote:
What I'd like to suggest is a change in the behavior of __autoload(),
so that multiple __autoload()'s could be defined. Essentially,
declaring __autoload() would in fact add the function to the list of
functions that are called in case a missing c
I dont know if you read the blog comments here:
http://www.akbkhome.com/blog.php/View/79/require_once+is+part+of+your
+documentation..html
and here
http://www.akbkhome.com/blog.php/View/77/is+__autoload+evil%3F.html
and slightly related
http://www.akbkhome.com/blog.php/View/76/require_once%2C+one
Zeev Suraski wrote:
At 15:18 03/04/2005, Andrey Hristov wrote:
Hi Zeev,
the idea one __autoload() may not be capable of loading therefore the
next
one in the chain should be executed to try to load/define the needed
code.
bool(false) returned from __autoload() means try with the next in the
cha
At 15:18 03/04/2005, Andrey Hristov wrote:
Hi Zeev,
the idea one __autoload() may not be capable of loading therefore the next
one in the chain should be executed to try to load/define the needed code.
bool(false) returned from __autoload() means try with the next in the chain,
bool(true) everythi
Zeev Suraski wrote:
All,
One problem that became apparent after the introduction of __autoload(),
is that different pieces of code, sometimes coming from different
sources, may want to declare this function in a different way. Today,
__autoload() is treated like any other function, so it's impo
At 14:21 03/04/2005, Andrey Hristov wrote:
Zeev Suraski wrote:
All,
One problem that became apparent after the introduction of __autoload(),
is that different pieces of code, sometimes coming from different
sources, may want to declare this function in a different way. Today,
__autoload() is tr
Zeev Suraski wrote:
All,
One problem that became apparent after the introduction of __autoload(),
is that different pieces of code, sometimes coming from different
sources, may want to declare this function in a different way. Today,
__autoload() is treated like any other function, so it's impo
All,
One problem that became apparent after the introduction of __autoload(), is
that different pieces of code, sometimes coming from different sources, may
want to declare this function in a different way. Today, __autoload() is
treated like any other function, so it's impossible to re-declare
Hi Stig,
Stig S. Bakken wrote:
> [un]register_class_autoload_function() would be even more useful.
See my previous post about Marcus' stuff:
$ sapi/cli/php -r "print_r(get_extension_funcs('spl'));"
Array
(
[...]
[3] => spl_autoload_register
[4] => spl_autoload_unregister
[...]
)
people
On Wed, 16 Mar 2005, Lukas Smith wrote:
> Hi,
>
> would it be possible to allow people to override the fixed name of
> __autoload() to a user defined function (static method?). I think this
> would be much more flexible and would probably also make it easier to
> exploit __autoload() inside cl
Hi,
would it be possible to allow people to override the fixed name of
__autoload() to a user defined function (static method?). I think this
would be much more flexible and would probably also make it easier to
exploit __autoload() inside class libraries. Especially as users are
likely to use
Hi,
Marcus Boerger schrieb:
Expected behavior that can be changed:
proto bool class_exists(string classname [, bool autoload])
"RTFM" or is it undocumented?
Ooops, didn't check the manual for class_exists() in the last months...
Stephan
--
http://www.php-tools.net
http://www.schst.net
http://pear.p
Hello Stephan,
Tuesday, February 22, 2005, 8:59:27 PM, you wrote:
> Hi,
> I just found this strange behaviour in PHP5:
> When using class_exists() to test, whether a class exists, the magic
> function __autoload() is called:
Expected behavior that can be changed:
proto bool class_exists(stri
Hi,
I just found this strange behaviour in PHP5:
When using class_exists() to test, whether a class exists, the magic
function __autoload() is called:
function __autoload($class)
{
echo "Trying to load $class\n";
}
if (!class_exists('DB')) {
echo "DB does not exist.\n";
}
You'll get:
Trying t
Hi,
It seems that for PHP5 to simply call __autoload() requires a massive .0040
seconds. Considering that each hit takes at least 30 classes, that's already
a tenth of a second gone on simply calling __autoload()! Why is it so slow?
My implementation should be extremely fast:
$LOCATION_TABLE=arra
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 do
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:
Andi Gutmans wrote:
At 01:06 PM 4/18/2004 -0400, Marc Richards wrote:
Andi Gutmans wrote:
At 12
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 (ass
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
-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 anyo
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 ge
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-
It gets called at run-time and should work with code-caches.
Andi
At 12:57 PM 4/18/2004 -0400, Marc Richards wrote:
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
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()
Hello, interals...
Kind of stumbled onto this by accident. Some kind of FD leak in streams. In
the current HEAD (and 5.0.0 RC1, I suppose, although I didn't specifically
test that, just my CVS checkout)...
class.one.php:
class.two.php:
foo.php:
[EMAIL PROTECTED] $ php5 foo.php
Warning
--- Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Please checkout the CVS and let me know if it works
> for you.
>
Hello Andi,
It seems to be working.
I´m going to make more tests. If anything goes wrong
I´ll tell you.
If somebody else would like to test, would help i
think.
regards,
Eduard
> --- Timm Friebe <[EMAIL PROTECTED]> wrote:
> > Andi Gutmans wrote:
> > Remember if anyone has posted a patch for this in
> > the past?
>
> I did:
> http://zend.com/lists/engine2/200306/msg00056.html
How about Marcus ideia http://zend.com/lists/engine2/200306/msg00078.html
___
On Tue, 2003-11-18 at 23:01, Andi Gutmans wrote:
> Yeah, this is something we need to tackle. i think we're going to have to
> keep the pretty case version but it's going to be a slight hit in performance.
> Remember if anyone has posted a patch for this in the past?
I did: http://zend.com/lists/
On Wed, 19 Nov 2003, Andi Gutmans wrote:
> Yes, this is definitely a problem. Today, when possible, we lowercase the
> class at compile-time so that we save time during execution. Supporting
> this will lead to a small slow down.
> I tend to agree that __autoload() should support this but I'm not
On Wed, 19 Nov 2003, Andi Gutmans wrote:
>At 11:09 AM 11/19/2003 -0800, Eduardo R. Maciel wrote:
>>Well,
>>
>>At the point the classname is passed to __autoload
>>is it already in lowercase???
>
>Yes it's already lowercase.
>We will need to keep it case-sensitive until this stage. Might not be
At 11:09 AM 11/19/2003 -0800, Eduardo R. Maciel wrote:
Well,
At the point the classname is passed to __autoload
is it already in lowercase???
Yes it's already lowercase.
We will need to keep it case-sensitive until this stage. Might not be too
bad because I have thought of a way of improving t
Well,
At the point the classname is passed to __autoload
is it already in lowercase???
If not, maybe you could just do a single stat in the
file the way it is defined in the __autoload()
function, with no sanity checks (to avoid performance
loss) and include it.
And warn users about it o
Yes, this is definitely a problem. Today, when possible, we lowercase the
class at compile-time so that we save time during execution. Supporting
this will lead to a small slow down.
I tend to agree that __autoload() should support this but I'm not sure if
we should change everything to run-time
Yeah, this is something we need to tackle. i think we're going to have to
keep the pretty case version but it's going to be a slight hit in performance.
Remember if anyone has posted a patch for this in the past? If not I'll try
and look into fixing it tomorrow.
Andi
At 09:42 AM 11/18/2003 -080
We run into a problem, when tryng to organize class
files since autoload always uses lowercase.
My class file, for example, is named
ArrayIterator.class.php (as the class ArrayIterator )
but I get the following error when trying to autoload
the class:
Warning:
__autoload(/usr/local/apache2/htdoc
At 07:17 AM 10/24/2003 -0700, Eduardo R. Maciel wrote:
Hi,
I agree with Dan´s opinion.
Watching from a point of view of a developer working
on PHP Object Oriented aplications, libs, frameworks,
etc, there is no sense on things like this. Or it IS
object oriented or it IS NOT. Partiality alway
Hi,
I agree with Dan´s opinion.
Watching from a point of view of a developer working
on PHP Object Oriented aplications, libs, frameworks,
etc, there is no sense on things like this. Or it IS
object oriented or it IS NOT. Partiality always run
into complications. And that was what happen on P
Hi Andi-
Yes, that explains things and makes perfect sense if you are just
writing your
own web application. Now, consider the new __autoload functionality from
a PEAR
or other large API/library developer standpoint.
The new __autoload functionality lets us:
- Keep library usage/installation s
Dan,
__autoload() is the last chance to load a class which is needed before
erroring out and terminating the script. By design, if you don't take
advantage of this last chance the script will error out. Therefore,
throwing an exception inside the __autoload() function should not be
catchable b
Hello Dan,
Sunday, October 12, 2003, 7:34:59 AM, you wrote:
> This behaviour isn't a show stopper. It's just the inconsistency that
> bugs me.
yes!
> I'm left wondering what other ways the engine might handle my exceptions
> that
> I might not expect, like...
> try {
> function __autoload($
Marcus-
Here are just some interesting observations with __autoload() and
exceptions:
Currently, an empty php file with just "throw new Exception();" will
dump out an
error like so: *Fatal error*: Uncaught exception 'exception' with
message 'Unknown exception' in
/server/http/sites/db.wep.net/
54 matches
Mail list logo
