Hi Dan,
The error was clear: the file containing the class foo was not found. But
before I made my post, I did run your test, just to make sure. It worked
fine[1] -- because my include_path is set to look at the current
directory first.
If you used my sample correctly you should get the same
exceptions thrown during autoload are ignored.
And one more thing, this is in the manual:
"Note: Exceptions thrown in __autoload function cannot be caught in the
catch block and results in a fatal error."
I think your explanation makes much more clear what happens, maybe it
would worth to up
YOu'd be surprised sometimes ;-) Anyway, exceptions thrown during
autoload are ignored. Autoloading is the last resort for the engine to
find a class. If the class can not be loaded (file isn't there,
exception, autoloader doesn't load a file), then you get the fatal
error. This is correct beha
Hi Dan,
The fact that the class "bar" is not found indicates that your include in
the autoload is either totally failing or gathering some other files.
Make your life better by specifying the path in the include statement
rather than relying on the include_path.
You totally missed the point.
Hi!
I think I found a bug but before posing it to bugs.php.net I would like
to ask your opinion. I think the it is not a planed behavior that some
errors doesn't "bubble up" from autoload, but at least the error message
is misleading.
-
foo.php:
bar
Hi!
Especially in a framework context there a lot of options how you can
make things more convenient, with
convention over configuration for example. In the end it might turn out
that a developer doesn't have
to type class names that often anymore and the length of such a name
gets less impor
Hi!
Yes, that's my point - 3X faster include opcode is not 3X faster code.
Of course if you do this opcode a lot of times, it would be somewhat
slower than if you do this opcode just one time. However, the question
is how it would influence the whole application?
I didn't say that the code wi
vserver. And the xdebug profiling result shows me in fact that this
additional time seems to be spend in the autoload facility and its
require_once calls.
OFF: require_once in autoload is not logical to me.
Best Regards,
Felhő
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
Hi!
Can you provide some benchmark setups that this could be researched -
i.e. describe what was benchmarked and how to reproduce it?
I have already played with this topic. If you don't have an opcode cache
lazy loading is a good solution: it is worth loading a code only when
it is needed. Bu
Hi!
Of course, we can't make parent:: reference the parent class of the called
one, as it would break BC.
As in:
class A { }
class B extends A { public static function test() { echo get_class(new
parent), '-', get_parent_class(); } }
class C extends B { }
C::test(); // A-A and not B-B
Maybe y
Hi!
Alexey Zakhlestin wrote:
I think a good example of php-technology would be symfony project +
caching in memcached
With symfony it is worth using Doctrine (a Hibernate-like ORM tool),
which has built-in caching possibility.
Best Regards,
Felhő
--
PHP Internals - PHP Runtime Development
Hi!
What do you want parent::test() to mean?
Because it wasn't. parent::test() means A::test(). 'parent::' means
'parent class of the class where this statement is' in PHP. For B, it's A.
When you use parent in your code you generally want to add some plus
functionality to the parent class. Bu
That would serve my purpose, as long as i can inherit methods and
properties from multiple parents.
Sorry if it is off to this list. Sam maybe you should check some PHP
mixins implementation:
http://www.symfony-project.org/book/1_0/17-Extending-Symfony#Mixins
http://www.achievo.org/blog/archives
also that would introduce BC issues.
Can you show a use case for BC?
Current implementation:
The __CLASS__ and the get_class() is the same like in the current PHP
version, and the get_called_class() is not yet introduced. Or do I
overlook something?
Best Regards,
Felhő
--
PHP Internals
As I and several others proposed earlier the best option would be:
parent::method() thinks it is the same class as a caller
ClassName::method() thinks it is ClassName
Yes, this would be the logical behavior for me too.
Best Regards,
Felhő
--
PHP Internals - PHP Runtime Development Mailing List
Actually, I don't think it was. If you want objects, why not use the
real thing?
Just consider that ZF's initial concept was for ActiveRecord a code
which needs LSB.
"more complex" is not always better.
Did you find my code example "too" complex? I think if LSB is added to
PHP there will be a
Hi!
this very subject was already discussed in a thread months ago.
I have read the thread about it, but I didn't find a conclusion (maybe I
missed it).
Basically,
it's a matter of choice whether fully established calls should break the
resolution or not.
I think the code I sent is an absol
Hi!
I read this thread, and I would like to ask if is there any decision
about the behavior of inheritance?
I wrote on my blog about late static binding
(http://blog.felho.hu/what-is-new-in-php-53-part-2-late-static-binding.html),
and I came up with the following example:
In think it w
Hi!
some of them might need to modify one array the other needs to modify
two arrays...
But every function knows the number of its own arguments, isn't it?
array otherwise func_get_args will butcher your references.
This behavior has nothing to do with the call-time-pass-reference
settings,
Say, you have a CMS which generally calls some kind of functions and
some of them might need to modify one array the other needs to modify
two arrays... Currently you need to wrap these into a "arguments"
array otherwise func_get_args will butcher your references.
In PHP6 allow_call_time_pass_ref
20 matches
Mail list logo
