Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63594
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 207.97.245.183 as permitted sender)
Message-ID: <50842CFB.5060807@sugarcrm.com>
Date: Sun, 21 Oct 2012 20:12:27 +0300
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: Clint Priest <cpriest@zerocue.com>, 
 PHP Internals <internals@lists.php.net>
References: <9570D903A3BECE4092E924C2985CE485612B53E4@MBX202.domain.local> <507D24E0.9070203@sugarcrm.com> <9570D903A3BECE4092E924C2985CE485612B6DC9@MBX202.domain.local> <507D5199.3090203@sugarcrm.com> <9570D903A3BECE4092E924C2985CE485612B6F1D@MBX202.domain.local> <507D6675.3080206@sugarcrm.com> <9570D903A3BECE4092E924C2985CE485612B7805@MBX202.domain.local> <507E846A.2030805@sugarcrm.com> <CAF+90c9_7OfzrA4n5KNmzD9kfj49k=8Mj38sZPutqFHHZP06yg@mail.gmail.com> <507E9550.8070602@sugarcrm.com> <CAF+90c_qcO9iyM3ijnxP7NERL5VksE_XnyuaiZfbMrSz=OdV8w@mail.gmail.com>
In-Reply-To: <CAF+90c_qcO9iyM3ijnxP7NERL5VksE_XnyuaiZfbMrSz=OdV8w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> 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.

Accessors are not "half-hidden" now - they are just methods. That's the
beauty and simplicity of it, and that's exactly why it works. I want to
keep the simplicity and not invent unnecessary complicated entities.
Keep it simple.

> It's all about making accessors accessors, rather than making them

Sorry, I don't understand the meaning of this. You obviously have a
preconception of how "accessors" should be, but please understand it's
only obvious and natural to you, because it's yours. To me, and I'm sure
to many other PHP users, it's an elaborate and complex, yet unnecessary
construct, that works almost like methods but subtly different for some
reason, and has no precedence in whole PHP history (and, actually, any
other dynamic language history, as far as I can see). In my
opinion, this is completely unnecessary, and even more - harmful. I'd
like to keep PHP simple and have just methods as methods, just as they
were in PHP for many years.

> 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,

This has nothing to do with precedence of variable access resolution,
and nobody proposes pseudo-methods. The whole point is I am proposing
*not* to do pseudo-methods, but use regular methods instead.

> Again, this has to be done anyway and is already done. Accessors
> need

It does not matter. Unnecessarily complicated code in the engine is bad
even if somebody already implemented it - because unneeded complexity is
always harmful and it hurts even more over time, as everybody needs to
support it and deal with it and make it work with all the rest of the
engine. Keeping it simple is a very high priority.

> 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.

That's what I think is completely wrong. They work exactly like methods
and that's what they should be.

> maybe during debugging or whatever). Now you either have to
> explicitly consider them in your code, for they are not actual
> methods, or the

They *are* actual methods, or they should be. You just don't want them
to be, but that's where it is wrong, because it creates unnecessary
complexity, both conceptual and technical.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227