Hi!
feels like this architectural decision -- separating properties and
methods into their own hash tables -- should be revisited. Most other
Having properties and methods in the same hash would make zero sense,
unless we convert all methods into closures - which I currently don't
feel we need to (though some languages do exactly that).
That, however, does not prevent us from prohibiting methods and vars
with the same name - what prevents us is described below.
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.
That is a question of expectations - if you expect properties and
methods be the same, it "just works", if you don't - it does not.
Currently there are two barriers to making it work:
1. Legitimate use-cases are easily done in user-land by using __call,
making all the effort kind of unnecessary.
2. It would create conflicting semantics in __get/__call which would
hugely complicate matters (e.g.: who gets called first and why? should
is_callable call __get? or maybe __isset? What happens if $this->a is a
string - should that work too? It works for $a... What if you have a
property named __get? etc, etc)
Without overcoming those barriers with some kind of solution I do not
see how we can make it work. Yes, I know it would be nice if we could
"just make it work", but unfortunately it's more complicated that that.
I feel "methods are different from properties" is much easier to
understand (even if one would wish it weren't so, it's still not hard to
comprehend) than "they are the same, except for a dozen of exceptions
and special cases when __get/__call is involved and they also different
from regular variables in these special cases, etc."
* 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.)
I'm afraid it's not a good approach. If it breaks substantial amount of
code, nobody is going to use it. And then it doesn't matter what you
think about that code because all the work would be for nothing.
* 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 don't like it, for two reasons:
1. Current patterns of PHP coding don't allow for raising exceptions
left and right - because people don't expect exceptions to come out of
ordinary things. That means the code would be very fragile - any
$foo->bar=1 turns into a bomb that could explode at any moment. It's
very hard to write robust code if you can't trust even a simple assignment.
2. What happens if you first assign closure to $this->a and then
integer? If you assigned closure to it it should work like a method,
right? Then it should prohibit assigning integer to it like methods do?
So you have assign-once variable? Quite a weird concept, don't you think?
Summarily, as I said, unfortunately generating consistent model that
would allow this use case to work without rewriting half of PHP is not
as easy as it seems. You (or anybody else) is welcome to try and prove
me wrong with a good RFC, though :) But take care to actually go a
number of steps beyond simplest use cases - that's where the trouble starts.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
