Re: RFC: Property get/set syntax (added isset/unset and references)

From: Date: Tue, 24 Apr 2012 12:56:55 +0000
Subject: Re: RFC: Property get/set syntax (added isset/unset and references)
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-60276@lists.php.net to get a copy of this message
Clint, Very nice job overall! Looking quite good. > Alternatively we could throw an error to a call on isset and/or unset against a property which > didn't define an implementation. I don't care for that concept much. All it's doing is trading one set of boilerplate for another. I'd prefer the get() !== null approach, since there is a zval allocated for it, so the isset() part. And I do like the unset overloading, which is right inline with __unset().... Additionally, is something like this possible? class Foo { private $bar = 1; public $bar { get { return $this->bar; } set { $this->bar = (int) $value; } } } The reason that I ask, is that's kind of what's done with __get() and __set() right now, the magic is called when it's out of scope. So in this case, we can have a public variable with the same name as the private one, but with validations attached to the public exposure... Just a thought... Anthony On Tue, Apr 24, 2012 at 8:31 AM, Clint M Priest <cpriest@zerocue.com> wrote: > I've updated the RFC to include details on adding isset/unset as well as references, > detailed below: > > isset/unset: > > class TimePeriod { >    private $Seconds = 3600; > >    public $Hours { >        get { return $this->Seconds / 3600; } >        set { $this->Seconds = $value; } >        isset { return !is_null($this->Seconds); } >        unset { $this->Seconds = NULL; } >    } > } > > References: > > > class SampleClass { > >    private $_dataArray = array(1,2,5,3); > > > >    public $dataArray { > >        &get { return &$this->_dataArray; } > >    } > > } > > > > $o = new SampleClass(); > > sort($o->dataArray); > > /* $o->dataArray == array(1,2,3,5); */ > > Comments? > > These would also include automatic implementations which call the respective functions on the > backing field.  I could see only allowing isset/unset automatic implementations if get/set were > also specified as automatic implementations. > > Default implementations of isset/unset > > I'm also fielding comments/ideas on a way to always provide automatic implementations of > isset/unset for any accessor that didn't define one automatically.  One idea was for the isset > (unspecified implementation) which would return true if the getter provided any value which > evaluated to true, such as this: > > class TimePeriod { >    private $Seconds = 3600; > >    public $Hours { >        get { return $this->Seconds / 3600; } >        set { $this->Seconds = $value; } >    } > } > /* Default Implementation Concept */ > >        isset { return (int)$this->Hours; } >        unset { $this->Hours = NULL; } > > Note that the automatic implementation of unset is not strictly the same as an unset() but > without any sort of unset implementation a call to unset() would do nothing.  Alternatively we > could throw an error to a call on isset and/or unset against a property which didn't define an > implementation. > > Thoughts? > > -Clint

« previous php.internals (#60276) next »