__call overload detection

19 years ago by Andrew Yochum — view source

unread

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 be something like __iscallable. Maybe
method_exists should remain as is, as the method won't ever really exist
but is_callable would/could use it, or perhaps some new function.

Is this a reasonable request? Thoughts?

Regards,
Andrew

Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

19 years ago by Andi Gutmans — view source

unread

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 be something like __iscallable. Maybe
method_exists should remain as is, as the method won't ever really exist
but is_callable would/could use it, or perhaps some new function.

Is this a reasonable request? Thoughts?

Regards,
Andrew

Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

19 years ago by Marcus Boerger — view source

unread

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 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 be something like __iscallable. Maybe
method_exists should remain as is, as the method won't ever really exist
but is_callable would/could use it, or perhaps some new function.

Is this a reasonable request? Thoughts?

Regards,
Andrew

Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

--

Best regards,
Marcus

19 years ago by Andi Gutmans — view source

unread

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 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 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 be something like __iscallable. Maybe
method_exists should remain as is, as the method won't ever really exist
but is_callable would/could use it, or perhaps some new function.

Is this a reasonable request? Thoughts?

Regards,
Andrew

Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

--

Best regards,
Marcus

19 years ago by Marcus Boerger — view source

unread

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().

At 04:05 PM 1/3/2006, Marcus Boerger wrote:

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 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 be something like __iscallable. Maybe
method_exists should remain as is, as the method won't ever really exist
but is_callable would/could use it, or perhaps some new function.

19 years ago by Andi Gutmans — view source

unread

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:24 PM 1/3/2006, Marcus Boerger wrote:

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().

At 04:05 PM 1/3/2006, Marcus Boerger wrote:

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 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 be something like __iscallable. Maybe
method_exists should remain as is, as the method won't ever really exist
but is_callable would/could use it, or perhaps some new function.

19 years ago by Andrew Yochum — view source

unread

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 unset. It is implemented as a "black
box" and has no complementary introspection method like isset to figure
out how the black box works - at least as part of the language. unset
has side-effects by nature of its intention, as might use of call.
isset is intended to be a no side-effect poke at a property, but no
such complement exists for call.

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.

100% agreed and I have done so.

I've brought it up for the community's benefit, as I think it is an area
that has room for some improvement. I can see it becoming an issue as
the frameworks and libraries for 5 continues to build and are
integrated. I don't want to argue either - just trying to have
productive discussion.

Regards,
Andrew

--
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

19 years ago by Stanislav Malyshev — view source

unread

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 much different - you know it will call __call but you don't
know if the call would succeed.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Derick Rethans — view source

unread

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 much different - you know it will call __call but you don't
know if the call would succeed.

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().

Derick

19 years ago by Stanislav Malyshev — view source

unread

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 succeed or fail -
just as calling any other functions may succeed or fail.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Marcus Boerger — view source

unread

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 could help me a lot
so that my error messages look and behave just like they would if there
is no __call. But that would indeed require some __exists() or
__implemented() support().

marcus

Wednesday, January 4, 2006, 10:24:20 AM, you wrote:

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 succeed or fail -
just as calling any other functions may succeed or fail.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Best regards,
Marcus

19 years ago by Stanislav Malyshev — view source

unread

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 help me a lot
MB>>so that my error messages look and behave just like they would if there
MB>>is no __call. But that would indeed require some __exists() or
MB>>__implemented() support().

Nothing prevents you from having __implemented or __whateveryoulike.
However, I don't see how engine could know beforehand if your __call would
succeed or not, so __implemented has no relation whatsoever to __call,
unless you make this relation in your code - and engine can't know you
did.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Lukas Smith — view source

unread

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 generation while the engine could help me a lot
MB>>so that my error messages look and behave just like they would if there
MB>>is no __call. But that would indeed require some __exists() or
MB>>__implemented() support().

Nothing prevents you from having __implemented or __whateveryoulike.
However, I don't see how engine could know beforehand if your __call would
succeed or not, so __implemented has no relation whatsoever to __call,
unless you make this relation in your code - and engine can't know you
did.

I think its obvious that you can implement things in userland or inside
the engine. The main advantage of doing it inside the engine is that it
then becomes the standard way of doing things, where as with userland
its likely that several competing "standards" will emerge. Not because
of real advantages, but just because of lack of a central standard.

However maybe its sufficient to just have an interface that defines the
signature of such a "check if method is implemented by __call()" method
along with a bit of text. That should imho be a sufficient approach.
Without the need of adding yet another magic method to the engine itself.

regards,
Lukas

19 years ago by Marcus Boerger — view source

unread

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, 2006, 12:50:56 PM, you wrote:

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 generation while the engine could help me a lot
MB>>so that my error messages look and behave just like they would if there
MB>>is no __call. But that would indeed require some __exists() or
MB>>__implemented() support().

Nothing prevents you from having __implemented or __whateveryoulike.
However, I don't see how engine could know beforehand if your __call would
succeed or not, so __implemented has no relation whatsoever to __call,
unless you make this relation in your code - and engine can't know you
did.

I think its obvious that you can implement things in userland or inside
the engine. The main advantage of doing it inside the engine is that it
then becomes the standard way of doing things, where as with userland
its likely that several competing "standards" will emerge. Not because
of real advantages, but just because of lack of a central standard.

However maybe its sufficient to just have an interface that defines the
signature of such a "check if method is implemented by __call()" method
along with a bit of text. That should imho be a sufficient approach.
Without the need of adding yet another magic method to the engine itself.

regards,
Lukas

Best regards,
Marcus

19 years ago by Stanislav Malyshev — view source

unread

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 to do in userland now?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Marcus Boerger — view source

unread

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 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 to do in userland now?

19 years ago by Stanislav Malyshev — view source

unread

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 not call a function and
you get the same.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Marcus Boerger — view source

unread

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
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 not call a function and
you get the same.

Best regards,
Marcus

19 years ago by Stanislav Malyshev — view source

unread

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 engine to integrate that
to. As I see it now, it's completely implementable userland and doesn't
require any engine support for it.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Stanislav Malyshev — view source

unread

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 because of real
LS>>advantages, but just because of lack of a central standard.

I don't see anything there to be implemented in the engine. What exactly
you want the engine to do? Only thing I can see is to support it in
is_callable() - I'm not sure if it worth it but we can do so that
is_callable would check if the object has __callable function or
implements interface CallableCheck or whatever and if it has, call it.
Though I'm not sure it really worth the hassle - all three people that
need it in real world probably already implemented it in userland anyway.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Lukas Smith — view source

unread

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 "standards" will emerge. Not because of real
LS>>advantages, but just because of lack of a central standard.

I don't see anything there to be implemented in the engine. What exactly
you want the engine to do? Only thing I can see is to support it in
is_callable() - I'm not sure if it worth it but we can do so that
is_callable would check if the object has __callable function or
implements interface CallableCheck or whatever and if it has, call it.
Though I'm not sure it really worth the hassle - all three people that
need it in real world probably already implemented it in userland anyway.

well in theory is_callable could also be called before __call() to save
people from having to duplicate the logic from __callable() and to have
the engine trigger the error. that is what i meant and like i said i do
not necessarily suggest doing that.

regards,
Lukas

19 years ago by Stanislav Malyshev — view source

unread

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 methods?
In 99.99% of cases you don't need it and actually you would have to
duplicate logic - once for handler that checks the callability and once
for the actual __call().

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Lukas Smith — view source

unread

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 should engine call additional methods?
In 99.99% of cases you don't need it and actually you would have to
duplicate logic - once for handler that checks the callability and once
for the actual __call().

I agree.
All we really need a central standard that people can adhere too and I
think this is within the scope of internals, but it does not need to be
handled by the engine itself.

regards,
Lukas

19 years ago by Marcus Boerger — view source

unread

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, you 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 should engine call additional methods?
In 99.99% of cases you don't need it and actually you would have to
duplicate logic - once for handler that checks the callability and once
for the actual __call().

Best regards,
Marcus

19 years ago by Stanislav Malyshev — view source

unread

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() and __call() which would
both be called and do the same logic on function call. You can not use
"some function pointer" from PHP.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Marcus Boerger — view source

unread

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 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() and __call() which would
both be called and do the same logic on function call. You can not use
"some function pointer" from PHP.

Best regards,
Marcus

19 years ago by Stanislav Malyshev — view source

unread

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 something alike __call - which is not C
side - and implementing it in PHP, which is not C side either. Obviously,
it is not what do you describe - so can you give some more explanation
what do you mean?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Marcus Boerger — view source

unread

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 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 something alike __call - which is not C
side - and implementing it in PHP, which is not C side either. Obviously,
it is not what do you describe - so can you give some more explanation
what do you mean?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Best regards,
Marcus

19 years ago by Marcus Boerger — view source

unread

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
MB>>>and dislike having all the others implemented automatically also. And the
MB>>>i have to care about error generation while the engine could help me a lot
MB>>>so that my error messages look and behave just like they would if there
MB>>>is no __call. But that would indeed require some __exists() or
MB>>>__implemented() support().

Nothing prevents you from having __implemented or __whateveryoulike.
However, I don't see how engine could know beforehand if your __call would
succeed or not, so __implemented has no relation whatsoever to __call,
unless you make this relation in your code - and engine can't know you
did.

Best regards,
Marcus

19 years ago by Peter Brodersen — view source

unread

On Wed, 4 Jan 2006 10:19:22 +0100 (CET), in php.internals
derick@php.net (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 (function names might exist but still
unusable), as mentioned in the documentation.

Peter Brodersen

19 years ago by Sara Golemon — view source

unread

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 be something like __iscallable. Maybe
method_exists should remain as is, as the method won't ever really exist
but is_callable would/could use it, or perhaps some new function.

This'll do what you want:

http://libssh2.org/dist/callable-1.0.tgz

It's PEAR packaged so compiling/installing should be simple enough.... Dunno
if it's worth dropping into PECL though...

-Sara

19 years ago by Andrew Yochum — view source

unread

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 be something like __iscallable. Maybe
method_exists should remain as is, as the method won't ever really exist
but is_callable would/could use it, or perhaps some new function.

This'll do what you want:

http://libssh2.org/dist/callable-1.0.tgz

It's PEAR packaged so compiling/installing should be simple enough.... Dunno
if it's worth dropping into PECL though...

-Sara

Thanks Sara. Nice to see that others have the need. Works like a
charm. You rock.

Marcus, is this along the lines of what you had in mind for the
(possible) implementation? This doesn't use interfaces, but that seems
trivial. I wasn't clear if you'd envisioned taking it one step further
and do the check before invocations of __call or not.

Regards,
Andrew

Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

19 years ago by Sara Golemon — view source

unread

This'll do what you want:

http://libssh2.org/dist/callable-1.0.tgz

Thanks Sara. Nice to see that others have the need. Works like a
charm. You rock.

Just for clarification. I didn't have a need for this, it's just something
I threw together today since it was simple...

Marcus, is this along the lines of what you had in mind for the
(possible) implementation? This doesn't use interfaces, but that seems
trivial. I wasn't clear if you'd envisioned taking it one step further
and do the check before invocations of __call or not.

I left interfaces out 'cause I wanted it to work easily with PHP4. As to
introducing the check prior to invoking __call()... that seems like
overkill. If __call() doesn't think it should be callable it should
trigger_error() or throw when its invoked that way. __callable() only has
meaning for avoiding the errors that calling an uncallable function would
produce.

-Sara

19 years ago by Andrew Yochum — view source

unread

Hi Marcus,

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, is_callable returns true for any requested method if __call
is implemented by the object. Unless I have missed some magic that the
Reflection APIs can do, they don't apply here.

Consider the following:
class a {
var $callables = array('foo');
function __call($name, $args) {
if ($this->__is_callable($name)) return 'good call';
else return 'bad call';
}
function __is_callable($name) {
return in_array($name, $this->callables);
}
}

$a = new a();
print "is_callable: " . is_callable(array($a,'foo'),false, $callable) . " as $callable \n";
// prints: is_callable: 1 as a::foo
// OK
print "is_callable: " . is_callable(array($a,'bar'),false, $callable) . " as $callable \n";
// result: is_callable: 1 as a::bar
// desired: is_callable: 0 as 
// or some other similar behavior if __is_callable is implemented

If one were to implement a reflection-like method called __iscallable,
you could get this functionality, but couldn't count on other's code
using the same convention. Another downside to doing it yourself is
that every call to a method must first check __is_callable - this could
be handled by the language upon a method call. If I feel it would be a
good idea to implement this in the lanaguage for standardization and
simplicity.

Regards,
Andrew

--
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

19 years ago by Marcus Boerger — view source

unread

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 to provide
the infrastructure. Remember we will not in anyway allow __call to handle
inheritance.

regards
marcus

Tuesday, January 3, 2006, 10:33:32 PM, you wrote:

Hi Marcus,

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, is_callable returns true for any requested method if __call
is implemented by the object. Unless I have missed some magic that the
Reflection APIs can do, they don't apply here.

Consider the following:
class a {
var $callables = array('foo');
function __call($name, $args) {
if ($this->__is_callable($name)) return 'good call';
else return 'bad call';
}
function __is_callable($name) {
return in_array($name, $this->callables);
}
}

$a = new a();
print "is_callable: " . is_callable(array($a,'foo'),false, $callable) . " as $callable \n";
// prints: is_callable: 1 as a::foo
// OK
print "is_callable: " . is_callable(array($a,'bar'),false, $callable) . " as $callable \n";
// result: is_callable: 1 as a::bar
// desired: is_callable: 0 as 
// or some other similar behavior if __is_callable is implemented

If one were to implement a reflection-like method called __iscallable,
you could get this functionality, but couldn't count on other's code
using the same convention. Another downside to doing it yourself is
that every call to a method must first check __is_callable - this could
be handled by the language upon a method call. If I feel it would be a
good idea to implement this in the lanaguage for standardization and
simplicity.

Regards,
Andrew

Best regards,
Marcus

19 years ago by Mike Naberezny — view source

unread

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, replace CLASS with
get_class($this) for private. I see very little or no real world application
for this and the procedure is quite expensive.

<?php
class Test {
public function __construct() {
// demo, should echo "hello"
echo $this->nonexistant;
}

 public function __get($offset) {
     try {
         throw new Exception();
     } catch (Exception $e) {
         $trace = $e->getTrace();
         $caller = isset($trace[2]['class']) ? $trace[2]['class'] : null;
         if ($caller === null
             || $caller != __CLASS__
             && !is_subclass_of($caller, __CLASS__)) {
                 throw new Exception('Access to protected ' .__CLASS__.

'::' .$offset. ' from context '. $caller);
}
}

     return 'hello';
 }

}

$t = new Test(); // hello
echo $t->nonexistant; // exception
?>

Mike

19 years ago by Sebastian Bergmann — view source

unread

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 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

19 years ago by Andrew Yochum — view source

unread

Hi Marcus,

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 to provide
the infrastructure. Remember we will not in anyway allow __call to handle
inheritance.

regards
marcus

Gotcha.

So to be clear, here's what the language has and behaves now:

__call allows for method overloading
interfaces, method_exists, and Reflection API tells if a physical
method exists - including __call method itself
is_callable tells if a method is callable (always true if __call
is implemented)
Calls to a non-existent method on classes w/ no __call overloading
results in a fatal error
Calls to a non-existent method on classes w/ __call overloading
succeeds, but result is undefined.

And how to use it:

Determining if a physical method exists is easy through interfaces,
method_exists, reflection APIs
Implementations of __call may do what they like with the invocations
such as ignore silently, trigger an error, throw an exception or
implement some other kind of custom protocol
To determine if a class implementing __call will respond to a method
invocation you must call it, regardless of side-effects, and must know
the protocol used by the class you're calling

I understand if the original intention was to use __call this way, and
that the language is not planned to change. I suggest such a change for
the benefit of the language and its users by providing consistency.

It seems this behavior of method overloading introduces an inconsistency
in the language that breaks the ease-of-use mantra of PHP. Why should a
class who uses method overloading behave differently than a class that
does not?

5.1 added the __isset and __unset methods for allowing property
overloading to behave consistently with regular properties, allowing
both classes that do and do not implement property overloading to behave
the same. It seems appropriate that the method overloading behave
similarly. An everyday end-user of the language should not need to know
if he's invoking or looking to invoke an overloaded method or not.

Regards,
Andrew

--
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

19 years ago by Marcus Boerger — view source

unread

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,

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 to provide
the infrastructure. Remember we will not in anyway allow __call to handle
inheritance.

regards
marcus

Gotcha.

So to be clear, here's what the language has and behaves now:

__call allows for method overloading

interfaces, method_exists, and Reflection API tells if a physical
method exists - including __call method itself

is_callable tells if a method is callable (always true if __call
is implemented)

Calls to a non-existent method on classes w/ no __call overloading
results in a fatal error

Calls to a non-existent method on classes w/ __call overloading
succeeds, but result is undefined.

And how to use it:

Determining if a physical method exists is easy through interfaces,
method_exists, reflection APIs

Implementations of __call may do what they like with the invocations
such as ignore silently, trigger an error, throw an exception or
implement some other kind of custom protocol

To determine if a class implementing __call will respond to a method
invocation you must call it, regardless of side-effects, and must know
the protocol used by the class you're calling

I understand if the original intention was to use __call this way, and
that the language is not planned to change. I suggest such a change for
the benefit of the language and its users by providing consistency.

It seems this behavior of method overloading introduces an inconsistency
in the language that breaks the ease-of-use mantra of PHP. Why should a
class who uses method overloading behave differently than a class that
does not?

5.1 added the __isset and __unset methods for allowing property
overloading to behave consistently with regular properties, allowing
both classes that do and do not implement property overloading to behave
the same. It seems appropriate that the method overloading behave
similarly. An everyday end-user of the language should not need to know
if he's invoking or looking to invoke an overloaded method or not.

Regards,
Andrew

--
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

Best regards,
Marcus

19 years ago by Andrew Yochum — view source

unread

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
andrew@plexpod.com
718-360-0879

19 years ago by Mike Naberezny — view source

unread

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 'method_name_1':
// handle method_name_1
break;
case 'method_name_2':
// handle method_name_2
break;
default:
throw new Exception('Call to undefined method ' . CLASS .
'::' . $method . '()');
}
}
}

$t = new Test();
$t->nonexistant();
?>

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.

Mike

19 years ago by Andrew Yochum — view source

unread

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 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 its
users and good clean code. That's very difficult if the classes it's
proxying for can't agree on a consistent behavior. The result might be
lots of special cases in various levels of code, not to mention the
possibility of a fatal error if any of the __call implementations try to
behave like the language does. A change in the language could eliminate
the ambiguity.

Regards,
Andrew

--
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

19 years ago by Mike Naberezny — view source

unread

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 its
users and good clean code. That's very difficult if the classes it's
proxying for can't agree on a consistent behavior. The result might be
lots of special cases in various levels of code, not to mention the
possibility of a fatal error if any of the __call implementations try to
behave like the language does. A change in the language could eliminate
the ambiguity.

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
will always be able to declare __call() without __iscallable(). This is quite
a contrast to implementing an interface such as ArrayAccess, where offsetSet()
and offsetExists() must always be defined in your class.

The interface enforces a public contract and the behavior of the object is
therefore always guaranteed, which is what you are seeking. In the case of
__iscallable(), its behavior can never have such a guarantee because
programmers may not declare it, so the inconsistency will always exist.

With that being said, I don't think __iscallable() is a bad idea. My only
reservation with adding it is that it's probably going to become even more
confusing for users to remember which magic methods are available in which PHP
versions.

Best,
Mike

19 years ago by Andrew Yochum — view source

unread

Hi Mike,

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
will always be able to declare __call() without __iscallable(). This is
quite a contrast to implementing an interface such as ArrayAccess, where
offsetSet() and offsetExists() must always be defined in your class.

The interface enforces a public contract and the behavior of the object is
therefore always guaranteed, which is what you are seeking. In the case of
__iscallable(), its behavior can never have such a guarantee because
programmers may not declare it, so the inconsistency will always exist.

With that being said, I don't think __iscallable() is a bad idea. My only
reservation with adding it is that it's probably going to become even more
confusing for users to remember which magic methods are available in which
PHP versions.

Best,
Mike

I whole-heartedly agree with the interface implementation vs. magic
methods. My current implementation uses interfaces. It seems that
most, if not all, magic method-like behavior might be interfaces down
the road. Just curious...what is the party line on that subject?

And does such an interface deserve to be part of SPL?

Regards,
Andrew

--
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

__call overload detection

Regards, Andrew

Regards, Andrew

Regards, Andrew

Regards, Andrew

Regards, Andrew

Regards,
Andrew

Regards,
Andrew

Regards,
Andrew

Regards,
Andrew

Regards,
Andrew