At 09:40 AM 4/8/2004 +0200, Marcus Boerger wrote:
> And I think __call has such few uses (I can think of one class right
> now: Object proxies for SOAP/ XMLRPC or the like) that you will hardly
> redeclare it anyway. If you start using __call on a regular basis you
> should probably rethink your de
Hello Christian,
Thursday, April 8, 2004, 8:09:20 AM, you wrote:
> Jochem Maas wrote:
>> I'm happy to just remove the P and add it again if ever that becomes an
>> option.
> Or go for the simpler option: Just don't use P.
> An addition to the documentation of __call saying that it has to be
>
Jochem Maas wrote:
I'm happy to just remove the P and add it again if ever that becomes an
option.
Or go for the simpler option: Just don't use P.
An addition to the documentation of __call saying that it has to be
public makes sense though. The meaning of PPP on __call would be
confusing anywa
George Schlossnagle wrote:
On Apr 7, 2004, at 9:28 PM, Jochem Maas wrote:
maybe its possible for the parser to ignore public/private/protected
declarations on __call() (& also __set(), __get()) methods, given PHP
forgiving nature/image (at least that is my impression).
The whole point of PPP
On Apr 7, 2004, at 9:28 PM, Jochem Maas wrote:
maybe its possible for the parser to ignore public/private/protected
declarations on __call() (& also __set(), __get()) methods, given PHP
forgiving nature/image (at least that is my impression).
The whole point of PPP is to not be forgiving or per
maybe its possible for the parser to ignore public/private/protected
declarations on __call() (& also __set(), __get()) methods, given PHP
forgiving nature/image (at least that is my impression).
at the very least spare php-general a ton of emails by mentioning it
prominently in the documentati
Hello Ferdinand,
that seems to be the current argument - but we have changed otehr places
like that already so we should make this feature request or even bug.
marcus
Monday, April 5, 2004, 1:18:57 PM, you wrote:
> On 5 Apr 2004 at 11:23, Derick Rethans wrote:
>> It is called from a public fun
On 5 Apr 2004 at 11:23, Derick Rethans wrote:
> It is called from a public function, how can that be outside of the
> class' point of view?
>
> Derick
Ah, now I understand your point. But __call() is called by the engine,
not by setup(), so it is the outside world
Class CallMe
{
publi
On Mon, 5 Apr 2004, Ferdinand Beyer wrote:
> On 5 Apr 2004 at 10:12, Derick Rethans wrote:
>
> > But it is not called from the outside world ...
>
> From the class' point of view: Yes, it is.
It is called from a public function, how can that be outside of the
class' point of view?
Derick
--
PH
On 5 Apr 2004 at 10:12, Derick Rethans wrote:
> But it is not called from the outside world ...
>From the class' point of view: Yes, it is.
--
Ferdinand Beyer
<[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 5 Apr 2004, Marcus Boerger wrote:
> Hello Jochem,
>
> using 'protected' for __call() hides that mechanism from the outside world,
> hence the behavior is correct. Just drop protected and it should work as you
> expect.
But it is not called from the outside world ...
Derick
--
PHP Inter
Hello Jochem,
using 'protected' for __call() hides that mechanism from the outside world,
hence the behavior is correct. Just drop protected and it should work as you
expect.
marcus
Sunday, April 4, 2004, 9:49:44 PM, you wrote:
> the following code does not do what I expect, I made this test ca
12 matches
Mail list logo
