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