Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63647
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.131 as permitted sender)
Message-ID: <508A9AC9.50200@sugarcrm.com>
Date: Fri, 26 Oct 2012 16:14:33 +0200
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Clint Priest <cpriest@zerocue.com>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <508A67E6.2000405@zerocue.com>
In-Reply-To: <508A67E6.2000405@zerocue.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method
 Visibility / Callability
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Some people are in favor of the internal functions being generated by an 
> accessor declaration should be invisible and non-callable directly. 
> Others are in favor of leaving them visible and callable.

I think these types are not right. It has nothing to do with
internals/userland, it has to do with wanting more magic that work is a
complex way while allowing user no knowledge and control over what's
going on, or reduced number of simple concepts that interact in a
variety of ways. You can say it's Windows model vs. Unix model, if you
need monikers.

> *Type 1 ( Userland Programmer )**
> *
> As a userland programmer, someone who cares nothing for "how" php works, 
> only how their own code works. If they define an accessor they expect to 
> see an accessor, reflection should reflect that there are accessors and 

Again, this insists on the notion that there's such accepted thing as
"accessor" in PHP field, which already has a known behavior and set of
expectations, and these match exactly the proposal of "invisible". But
this is not true at all - only successors existing so far in PHP are
regular perfectly visible methods. So if you expect to see an accessor,
you expect to see __get. If you appeal to natural expectations of PHP
user, you can not argue it is "for accessors to be accessors", because
PHP has never had anything like you proposed, and there's no any
accepted definition of "accessor" that implies what you are implying.

> no other "methods" they did not explicitly define. If they were to 
> reflect on all of the methods of their class and see a number of 
> __getHours() they may be confused as to why or where this function came 

Please do not insult the intelligence of PHP users. They are not some
mindless creatures that given property Hours, previous existence of
__get and __getHours can not figure out what's going on, even after
being told of the new accessors feature (since they're using it in the
code). They won't be confused. Nobody knowing how to program a
hello-world would. This mythical easily-confusable users do not exist,
but if they did, they'd just not use reflection because it'd be too
confusing for them anyway.

> than specially formatted and called methods on the class. This can be 
> understandable because you want all information available to you. You 

This has very little to do with information available. This has
everything to do with

> would probably not be confused if you wrote $obj?abc = 1 and got back an 
> error like "Fatal Error: Class->__setAbc() function does not exist.

You can very easily handle the error in the same handler that you look
for setter, this is not an issue at all. In general, error messages have
very little to do with the whole thing. If the error messages is the
thing you're worried about - it should be trivially easy to fix, since
all access will go through object handlers anyway, and the object
handler would decide to throw the error - so you'd be able very easily
to issue any error message you like.

> *Unfortunately 80 to 95% of all people who use PHP are of the first type.**

Not really. There are a lot of programmers that aren't Windows type, and
prefer simple interfaces to ones with a lot of complicated magic. --
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227