On Wed, Oct 17, 2012 at 1:24 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> Hi!
>
>> You have already written seven mails all saying how much complexity
>> this would introduce. Could you maybe elaborate a bit on that? How
>> would it make anything more complex? I mean, the only really
>
> Any code that deals with methods would now have to consider - is this
> regular method or special "uncallable" method? Can I call it? Can I list
> it in the list of class methods?
I think we are still not on the same page here. The exact point is to
*not* put accessors into the method table. As such the accessors
aren't special, half-hidden methods (like they are with the current
implementation), rather they are *just* accessors and nothing else.
As this seems hard to understand, consider the following code:
class Foo {
public $foo = [
'get' => function() { return $something; },
'set' => function($value) { $something = $value; },
];
}
Rather than:
class Foo {
public $foo = [
'get' => [$this, '__getFoo'],
'set' => [$this, '__setFoo'],
];
public function __getFoo() { return $something; }
public function __setFoo($value) { $something = $value; }
}
The above obviously isn't working PHP code, but I hope that it makes
the difference a bit clearer.
It's all about making accessors accessors, rather than making them
references to automagically generated methods representing the
accessors.
> And all inheritance functions will have to consider them
> separately from all other methods, etc.
Accessors need to be considered separately anyway, otherwise you end
up with the problems that we currently have, where you can't override
a property with an accessor in an extending class or the other way
around. Having those pseudo-methods makes this even more complicated,
because now you could have these inherited pseudo-methods still around
in your class, even though you don't have the accessor anymore. And
stuff like that.
> And interface implementation has to be changed to account for existence of
> not-quite-methods.
Again, this has to be done anyway and is already done. Accessors need
different implementation checks than methods. See the interfaces
thread.
> Even conceptually, you need to be aware that there are methods of class
> and then there are non-methods which look exactly like methods in almost
> every aspect but aren't.
I think it's the other way around. As I already said above, the
accessors won't be methods. So you don't have to consider anything.
*Right now* you need to consider on the other hand. Right now there
methods and then there are autogenerated accessor methods, and they
will show up everywhere you are analyzing classes with reflection (or
maybe during debugging or whatever). Now you either have to explicitly
consider them in your code, for they are not actual methods, or the
PHP implementation has to try to hide them. And then you end up with
the issues you mentioned above. Not having them as methods in the
first place does not cause any of those issues, at least not as far as
I can see.
Etc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
