Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37857
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Sun, 25 May 2008 10:57:22 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <104525707.20080525105722@marcus-boerger.de>
To: Daniel Convissor <danielc@analysisandsolutions.com>, 
	Sara Golemon <pollita@php.net>
CC: PHP Internals List <internals@lists.php.net>
In-Reply-To: <20080405132733.GA6531@panix.com>
References: <20080405132733.GA6531@panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Overloading Clarifications for Manual
From: helly@php.net (Marcus Boerger)

Hello Daniel,

Saturday, April 5, 2008, 3:27:33 PM, you wrote:

> [Hmm... No answer in several days.  Let's try this again with a 
> different subject]

> I'm in the middle of clarifying the Overloading section of the manual,
> http://docs.php.net/manual/en/language.oop5.overloading.php.  Some issues 
> and questions have come up and your insights will be helpful, please.

> * The docs say "All overloading methods must be defined as public."  At 
> this point (in 5.2.1 and 5.3.0 snapshot) all visibility declarations are 
> ignored:

>     class bug_43924 {
>         private function __call($name, $arguments) {
>             echo $name . "\n";
>         }
>     }

>     $obj = new bug_43924;
>     $obj->ObjectContext();

> Is this an oversight in the engine?  Are there plans to have the parser 
> enforce the public declaration?

We experimented with visibility and ran into trouble.

And just to confirm this:
[marcus@zaphod PHP_5_3]$ php -r 'class T{public function __call($n, $a){var_dump($n);}} $o=new T; $o->foo(); ReflectionMethod::export("T","__call");'
make: `sapi/cli/php' is up to date.
string(3) "foo"
Method [ <user> public method __call ] {
  @@ Command line code 1 - 1

  - Parameters [2] {
    Parameter #0 [ <required> $n ]
    Parameter #1 [ <required> $a ]
  }
}

[marcus@zaphod PHP_5_3]$ php -r 'class T{protected function __call($n, $a){var_dump($n);}} $o=new T; $o->foo(); ReflectionMethod::export("T","__call");'
make: `sapi/cli/php' is up to date.
string(3) "foo"
Method [ <user> protected method __call ] {
  @@ Command line code 1 - 1

  - Parameters [2] {
    Parameter #0 [ <required> $n ]
    Parameter #1 [ <required> $a ]
  }
}

So we in fact note the visibility but then ignore it.

I think we either need to respect the visibility or issue an error if it
is not public. Please file a but report.

> * Along these lines, it would be an interesting new feature if one could 
> declare any visibility for the overloading methods and have the engine 
> observe them.  This could allow people to use overloading for internal 
> calls but skip them for external calls.

As said there were issues with this approach. Issues as in it wouldn't be
working as expected under all circumstances. So making ti possible would
eventually only increase the WTF factor.

> * Some user comments say they find it helpful to have their __get() 
> methods return by reference.  Doing so is allowed at this point.  Is this 
> kosher?  Will it remain so?

I think it is a bug. But iirc it was designed to either allow &__get() or
__get() for all derived classes. Does anyone remember?

> * The value of $name in __call() is case sensitive, but in the newly 
> added __callStatic() $name is lower case.  Is this intentional?  It seems 
> the two methods should have the same behavior.

It isn't for function calls so this is the correct behavior.

> * The new __callStatic() is neat.  Thanks.  Is there consideration of 
> adding Static versions of the other overloading methods?

Sara maybe?

> Thanks,

> --Dan

> -- 
>  T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
>             data intensive web and database programming
>                 http://www.AnalysisAndSolutions.com/
>  4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409




Best regards,
 Marcus