MB the point is probably that there is no way in determinig whether a
MBcertain function is supposed to work prior to calling it.
This is the case for all functions. For example, if you call mysql_query,
you have no way of knowing if it would succeed prior to calling it. So
__call is not much
On Wed, 4 Jan 2006, Stanislav Malyshev wrote:
MB the point is probably that there is no way in determinig whether a
MBcertain function is supposed to work prior to calling it.
This is the case for all functions. For example, if you call mysql_query,
you have no way of knowing if it would
DRThat is not fully true, as you can use function_exists() on
DRmysql_query, where there is no such possibility for methods that are
DRoverloaded with __call().
That's correct, of course - this is the whole point of __call - it makes
_any_ function exist. Now, calling these functions may
Hello Stanislav,
but that is a way of having __call that obviously doesn't fit the real
world. In a real world application i only implement a few things with call
and dislike having all the others implemented automatically also. And the
i have to care about error generation while the engine
MB but that is a way of having __call that obviously doesn't fit the real
MBworld. In a real world application i only implement a few things with call
MBand dislike having all the others implemented automatically also. And the
MBi have to care about error generation while the engine could help me
On Wed, 4 Jan 2006 10:19:22 +0100 (CET), in php.internals
[EMAIL PROTECTED] (Derick Rethans) wrote:
That is not fully true, as you can use function_exists() on mysql_query,
where there is no such possibility for methods that are overloaded with
__call().
.. with some exceptions though
Stanislav Malyshev wrote:
MB but that is a way of having __call that obviously doesn't fit the real
MBworld. In a real world application i only implement a few things with call
MBand dislike having all the others implemented automatically also. And the
MBi have to care about error generation
Hello Lukas,
that's right now also impossible. We would need an api change for that.
Or we would need to have the interface support deeply in the engine like
we have with the iterators. If that is ok for all among the engine
developers i think i can easily add it.
marcus
Wednesday, January 4,
LSI think its obvious that you can implement things in userland or inside the
LSengine. The main advantage of doing it inside the engine is that it then
LSbecomes the standard way of doing things, where as with userland its likely
LSthat several competing standards will emerge. Not because of real
Stanislav Malyshev wrote:
LSI think its obvious that you can implement things in userland or inside the
LSengine. The main advantage of doing it inside the engine is that it then
LSbecomes the standard way of doing things, where as with userland its likely
LSthat several competing standards will
Stanislav Malyshev wrote:
LSwell in theory is_callable could also be called before __call() to save
LSpeople from having to duplicate the logic from __callable() and to have the
LSengine trigger the error. that is what i meant and like i said i do not
That would be major slowdown - why should
Hello Stanislav,
how is this a major slowdown? It would add a simple pointer check at
runtime and two places to set the pointer, one place will initialize it to
NULL and the other will store some function pointer just like all the other
__*()'s do.
marcus
Wednesday, January 4, 2006, 4:13:02
MB that's right now also impossible. We would need an api change for that.
MBOr we would need to have the interface support deeply in the engine like
MBwe have with the iterators. If that is ok for all among the engine
MBdevelopers i think i can easily add it.
What exactly is impossible to do in
Hello Stanislav,
both will have a function pointer on the c side so the major slowdown you
spoke of will only be there if one actually wants it. Otherwise there will
be only the pointer check.
marcus
Wednesday, January 4, 2006, 5:28:01 PM, you wrote:
MB how is this a major slowdown? It
Hello Stanislav,
having non supported dynamic calls behave in the same way as build in or
user code methods.
marcus
Wednesday, January 4, 2006, 5:30:51 PM, you wrote:
MB that's right now also impossible. We would need an api change for that.
MBOr we would need to have the interface support
MB both will have a function pointer on the c side so the major
MBslowdown you spoke of will only be there if one actually wants it.
MBOtherwise there will be only the pointer check.
I think you lost me. What exactly you are describing here? I though we
were talking about implementing
MB having non supported dynamic calls behave in the same way as build
MBin or user code methods.
As defined code methods? Make your __call always return true and that is
what you'd get, not? Or you want it to behave as undefined methods? Then
make your __call to throw and error once it can
Hello Stanislav,
the point is integration but i see no point for further dicussion
unless you are willing to reread the thread and accept what we were
talking about here.
Wednesday, January 4, 2006, 6:02:41 PM, you wrote:
MB having non supported dynamic calls behave in the same way as build
Hello Stanislav,
just again, the point is integration so that you know whether it makes
any sense to call soemthing or not without having to check for errors
after the call.
marcus
Wednesday, January 4, 2006, 5:59:59 PM, you wrote:
MB both will have a function pointer on the c side so the
MB the point is integration but i see no point for further dicussion
MBunless you are willing to reread the thread and accept what we were
MBtalking about here.
I won't talk to you unless you agree with me. Nice. Anyway, I don't see
any point in integration and any place in the engine to
Hi Marcus,
On Tue, Jan 03, 2006 at 10:06:56PM +0100, Marcus Boerger wrote:
Hello Andrew,
right now you can use reflection.
marcus
The reflection APIs do not help I believe. Consider that one may only
want __call to respond to a computable set of overloaded method names.
Right now,
Hello Andrew,
you do not implement __call for a method but you deal with the method name
in any sense you like, which also includes ignoring specific __call
invocations. Reflection gives you the ability to check whetehr a function
is being physically available. If you need more it is up to you
Hi Andrew,
Andrew Yochum wrote:
Consider that one may only
want __call to respond to a computable set of overloaded method names.
Usually, this is done by something like this:
?php
class Test {
public function __call($method, $args) {
switch ($method) {
case
Why not just use Reflection API to check? It seems quite trivial to do so.
At 12:57 PM 1/3/2006, Andrew Yochum wrote:
Currently there is no way to detect if the __call overloads a particular
method. Property overloading has __isset now in 5.1 - maybe for method
overloading the equivalent
Marcus Boerger wrote:
If you need more it is up to you to provide
the infrastructure. Remember we will not in anyway allow __call to handle
inheritance.
Hi Marcus,
If one is determined enough, at least visibility can be faked by exception
trace introspection. Below demonstrates protected,
Hello Andi,
the point is probably that there is no way in determinig whether a
certain function is supposed to work prior to calling it.
regards
marcus
Wednesday, January 4, 2006, 12:45:23 AM, you wrote:
Why not just use Reflection API to check? It seems quite trivial to do so.
At 12:57
Right but you can do it in user-land. If you're writing __call() you
could add an additional method to see if it's mapped. I don't think
it's quite as common as isset().
At 04:05 PM 1/3/2006, Marcus Boerger wrote:
Hello Andi,
the point is probably that there is no way in determinig
Hello Andrew,
you got everything correct and i see your point, so you may want to open a
feature request under bugs.php.net.
marcus
Wednesday, January 4, 2006, 1:37:26 AM, you wrote:
Hi Marcus,
On Tue, Jan 03, 2006 at 10:50:24PM +0100, Marcus Boerger wrote:
Hello Andrew,
you do not
Hello Andi,
we didn't saw any necessaty for __isset either.
marcus
Wednesday, January 4, 2006, 1:41:44 AM, you wrote:
Right but you can do it in user-land. If you're writing __call() you
could add an additional method to see if it's mapped. I don't think
it's quite as common as isset().
I think it's different especially as it's complementary to unset()
but I don't intend to get into an argument about it.
In any case, the tools for Andrew to resolve this programmatically on
the PHP level exist even if the syntax isn't 100% of what he'd like it to be.
Over and out.
Andi
At
On Tue, Jan 03, 2006 at 03:44:33PM -0800, Mike Naberezny wrote:
I see your point with detection by something like __is_callable(), although
I can't personally think of a place where I'd use it.
Consider a situation where a proxy/mediator/broker class implementing
__call proxyies method calls
On Tue, Jan 03, 2006 at 05:29:11PM -0800, Andi Gutmans wrote:
I think it's different especially as it's complementary to unset()
but I don't intend to get into an argument about it.
I see your point there about isset and unset being a matched pair. From
my perspective, call is similar to
Andrew Yochum wrote:
Consider a situation where a proxy/mediator/broker class implementing
__call proxyies method calls to other classes (possibly of 3rd party
origins), which themselves may or may not implement __call. You'd like
the broker itself to have a consistent behavior for the sake of
On Wed, Jan 04, 2006 at 02:23:51AM +0100, Marcus Boerger wrote:
Hello Andrew,
you got everything correct and i see your point, so you may want to open a
feature request under bugs.php.net.
marcus
Thanks. Will do.
Regards,
Andrew
--
Andrew Yochum
Plexpod
[EMAIL PROTECTED]
718-360-0879
Hi Mike,
On Tue, Jan 03, 2006 at 06:05:31PM -0800, Mike Naberezny wrote:
Hi Andrew,
I understand your scenario and I agree but I think that this would be
better done in userland by implementing an interface.
Remember that all of the magic methods do not need to be declared, i.e. you
Mike Naberezny schrieb:
If one is determined enough, at least visibility can be faked by
exception trace introspection.
You do not need exceptions for this, just use debug_backtrace().
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7
36 matches
Mail list logo
