Re: [RFC] Propety Accessors v1.1

From: Date: Fri, 12 Oct 2012 08:29:33 +0000
Subject: Re: [RFC] Propety Accessors v1.1
References: 1 2 3 4 5 6 7 8 9 10 11 12 13  Groups: php.internals 
Request: Send a blank email to internals+get-63363@lists.php.net to get a copy of this message
2012/10/12 Clint Priest <cpriest@zerocue.com> > I guess I didn’t see any other support for it from others > Well, I get some bad replies (mainly from Andrew), but good ones too. Some people (like Matthew) said it was an elegant syntax... > and it is a subset of what the RFC I am proposing would encompass > Yes it's true, my proposal was focusing on a subset of your RFC. But this subset is - from my experience - the main usage of accessors. More, both can work together: My syntax could be used to define the visibility of reading and writing access, while yours is perfect to add processing on these accesses. > did I miss something with your original email? > I don't know. It's a matter of choice. I prefer to write: public:protected $a; protected:const $b; Rather than: public $a { protected set; } protected read-only $b; I saw you removed your new keywords. I think it's a good thing, because "const" was already here (no need for "read-only"). As I said, both syntaxes can work together. For example: public:protected $a { get() { return ($this->_prefix . $this->_a); } set($val) { $this->_a = substr($val, 1); } } The visibility is defined first (how I can use this property?), and then the code is available if needed (how does it work?). It's the same logic than when you write "private static function foo() { ... }". Maybe I'm the only one thinking we can imagine an elegant and understandable syntax that doesn't need to mimic what C# does. But still. :-)

« previous php.internals (#63363) next »