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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
