Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63690
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.184 cause and error)
Message-ID: <508D1998.6020200@lsces.co.uk>
Date: Sun, 28 Oct 2012 11:40:08 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120826 Firefox/15.0 SeaMonkey/2.12
MIME-Version: 1.0
To: internals@lists.php.net
References: <508A67E6.2000405@zerocue.com>	<508A9AC9.50200@sugarcrm.com> <CAF+90c-VmscV0q=RAk7FE6+RLhjY8t9CRGY7QqpjB+3=b2XJTQ@mail.gmail.com> <508AF3E7.7020004@sugarcrm.com> <CAF+90c-RXwG7r=BW6_pDjRTaO3vJx6fGJhdwXV38GqHfBZNHVw@mail.gmail.com> <508B1EA2.8060203@sugarcrm.com> <508C249D.1000309@zerocue.com> <508C43ED.9000209@sugarcrm.com> <508C80C6.9000008@zerocue.com> <508CD916.1070509@sugarcrm.com>
In-Reply-To: <508CD916.1070509@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method
 Visibility / Callability
From: lester@lsces.co.uk (Lester Caine)

Stas Malyshev wrote:
>> By accessors I am simply referring to getters, setters (and in the case
>> >of php, issetter and unsetter).
> I wish it was so, but it was mentioned many times in this discussion
> that "accessors should be accessors" and that only the situation where
> accessors are special functions that are not defined as regular methods,
> are not callable and are hidden from reflection, etc. is the situation
> where "accessors are accessors". This is not the case in Python, Ruby,
> MS C++, D and Delphi by your own link - in all these cases, the
> properties are defined as regular methods (possibly with some special
> salt added) and no special effort is taken to hide them from any of the
> language facilities and make them not callable.

While I will probably be shouted down again ... can we clarify WHAT people are 
trying to achieve here?

__get and __set simply provide a crude means of using '$data' array to store 
properties in an object without having to define and load them every time. It 
has very limited use and in my own opinion is simply wrong anyway. But people 
seem to like to use it rather than simply defining their own $data array and 
accessing it directly? The reason it does not work for me is that I populate the 
data array ( in my case $mInfo ) directly from the persistent data in a 
database, and __get and __set simply do not work with this so never get used.

I can SEE the logic behind a get and set arrangement being 'formalised', and 
mirroring __get and __set is obviously necessary, but part of the reason for 
this discussion was - I thought - a way of allowing get/set to manage access to 
internal data that may not be a simple mirror, but rather calculated from other 
internal data ( hours based on second count )? 'Internal Accessor Method 
Visibility' needs to provide the user with information on how a returned value 
was generated? Even if that is only via documentation? Debugging that the 
process is working is the thing that gets difficult if you can 'see' the process.

The discussion has been 'split up', but I see 'Extra shorthand declaration' as 
another hiding of visibility such that 'public DateTime $date;' completely 
bypasses setting up the DateTime object and that $date will have it's own 
'accessors' or rather methods for accessing and configuring the object and it's 
values!

PHP has something no other language has - 'very flexible arrays' - and we can 
manage and pass data very nicely using these properly. Pass by reference allows 
complex data to be passed and massaged in a way that 'accessors' simply can't 
provide, and it's this method of working that we should be promoting rather than 
trying to hide things 'because the user does not need to know about them'. 
Everything used to be nicely visible in PHP, but that is becoming less the case 
and getting back to a framework where the IDE can provide all of the 'eye-candy' 
that is not needed when simply running the scripts should be considered as well?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk