MB>> the point is integration but i see no point for further dicussion
MB>>unless you are willing to reread the thread and accept what we were
MB>>talking 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 engin
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
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 buil
MB>> having non supported dynamic calls behave in the same way as build
MB>>in 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
MB>> both will have a function pointer on the c side so the major
MB>>slowdown you spoke of will only be there if one actually wants it.
MB>>Otherwise 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 so
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.
MB>>>Or we would need to have the interface sup
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 wo
MB>> that's right now also impossible. We would need an api change for that.
MB>>Or we would need to have the interface support deeply in the engine like
MB>>we have with the iterators. If that is ok for all among the engine
MB>>developers i think i can easily add it.
What exactly is impossible t
MB>> how is this a major slowdown? It would add a simple pointer check at
MB>>runtime and two places to set the pointer, one place will initialize it to
MB>>NULL and the other will store some function pointer just like all the other
MB>>__*()'s do.
You would have two PHP functions: __callable() a
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 PM
Stanislav Malyshev wrote:
LS>>well in theory is_callable could also be called before __call() to save
LS>>people from having to duplicate the logic from __callable() and to have the
LS>>engine trigger the error. that is what i meant and like i said i do not
That would be major slowdown - why sho
LS>>well in theory is_callable could also be called before __call() to save
LS>>people from having to duplicate the logic from __callable() and to have the
LS>>engine trigger the error. that is what i meant and like i said i do not
That would be major slowdown - why should engine call additional m
Stanislav Malyshev wrote:
LS>>I think its obvious that you can implement things in userland or inside the
LS>>engine. The main advantage of doing it inside the engine is that it then
LS>>becomes the standard way of doing things, where as with userland its likely
LS>>that several competing "standa
LS>>I think its obvious that you can implement things in userland or inside the
LS>>engine. The main advantage of doing it inside the engine is that it then
LS>>becomes the standard way of doing things, where as with userland its likely
LS>>that several competing "standards" will emerge. Not becaus
Hello Stanislav,
where is the relation between __isset and __get/set/unset?
marcus
Wednesday, January 4, 2006, 12:32:29 PM, you wrote:
MB>>> but that is a way of having __call that obviously doesn't fit the real
MB>>>world. In a real world application i only implement a few things with call
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,
Stanislav Malyshev wrote:
MB>> but that is a way of having __call that obviously doesn't fit the real
MB>>world. In a real world application i only implement a few things with call
MB>>and dislike having all the others implemented automatically also. And the
MB>>i have to care about error genera
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 (func
MB>> but that is a way of having __call that obviously doesn't fit the real
MB>>world. In a real world application i only implement a few things with call
MB>>and dislike having all the others implemented automatically also. And the
MB>>i have to care about error generation while the engine could
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 coul
DR>>That is not fully true, as you can use function_exists() on
DR>>mysql_query, where there is no such possibility for methods that are
DR>>overloaded with __call().
That's correct, of course - this is the whole point of __call - it makes
_any_ function exist. Now, calling these functions may
On Wed, 4 Jan 2006, Stanislav Malyshev wrote:
> MB>> the point is probably that there is no way in determinig whether a
> MB>>certain 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
MB>> the point is probably that there is no way in determinig whether a
MB>>certain 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 m
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
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
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
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 i
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 uns
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
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 05:
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(
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
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 whethe
Hi Marcus,
On Tue, Jan 03, 2006 at 10:50:24PM +0100, Marcus Boerger wrote:
> 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 chec
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
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, re
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 should
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:
throw new Exception('Call to undefined method ' . __CLASS__ .
'::' . $method . '()');
}
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 t
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,
40 matches
Mail list logo
