On 2010-09-29, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> >      public function __construct()
> >      {
> >          $this->a = new A();
> >          $this->a();
>
> Here you are calling method a() of object $this. Such method does not 
> exist. No bug here. Methods are properties are different things.

I completely understand why it works the way it does. That said, with
the various new language features such as __invoke() and closures, it
feels like this architectural decision -- separating properties and
methods into their own hash tables -- should be revisited. Most other
dynamic languages do not allow having properties and methods of the same
name precisely to prevent the possibility of collisions -- and to allow
extensions to a class just like the above illustration.

The fact that a lot of folks playing with 5.3 are running into issues
like this and wondering why it doesn't work indicates that the design
needs to change to be more easily predictable. Assigning a closure or
other invokable to a class should "just work" -- developers shouldn't
need to know how the Zend Engine works in order to understand the
behavior and limitations.

Of course, making such a change would open up a number of other issues:

 * BC break for existing codebases that have properties and methods of
   the same name. (That's a code smell, anyways, and tools can help
   developers refactor to fix such cases.)

 * What if method "a" exists, and a developer tries to re-assign it as a
   closure or property? JavaScript and Ruby allow this; PHP wouldn't
   necessarily need to -- e.g. could raise an exception. Whatever the
   choice, just need to cleanly document the behavior. Again, potential
   BC break.

I personally think the BC breaks here are worth it -- they make the
behavior more predictable, easier to document, and easier to understand.

-- 
Matthew Weier O'Phinney
Project Lead            | matt...@zend.com
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to