Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65144
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.132 cause and error)
Message-ID: <51011448.6060401@lsces.co.uk>
Date: Thu, 24 Jan 2013 11:00:24 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14
MIME-Version: 1.0
To: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Accessors in general
From: lester@lsces.co.uk (Lester Caine)

I've kept my head down since it's obvious that there is still no consensus as to 
how the latest accessors system will work including an RFC to change what is 
being proposed if it's accepted anyway? THAT is just wrong!

Part of the problem I see is that people want to replace the __get/__set version 
which was a previous iteration with something that 'works better' but can still 
co-exist with that. Is THIS part of the problem? As is my way, I've never used 
__get/__set simply because it always felt wrong. I want code that relates to the 
variable directly rather than having to hard code every variable into the 
getter/setter? Now we are looking at 'bodges' to allow a new system to co-exist 
with something which people find faulty? vd() works well for me fault finding 
since day 1 and having to rewrite that to show what is going on under the hood 
does not make sense to me.

Perhaps the whole problem here is the fact that BC is sacrosanct when perhaps it 
would make sense to produce a proper fork from something that is not working 
well? Much like traits is getting a proper overhaul - even if some of us will 
never use it. Pushing new things in which are a 'compromise' already is not the 
way to be improving the language?

People keep going on about reducing boilerplate code side so there is less to 
type, but with the right EXTERNAL tools many of the complaints simply evaporate 
and so the feeling I am seeing in the accessors debate is "does the additional 
complexity really justify the savings?" Does the core code actually need to be 
loaded down with ALL these additions when there are other ways to achieve the 
same results?

-- 
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