RE: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and references)

From: Date: Wed, 25 Apr 2012 00:12:38 +0000
Subject: RE: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and references)
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-60304@lists.php.net to get a copy of this message
That makes sense to me, a number (possibly all) of the errors I've added/modified could be eligible for this. In those cases it would do "the next best thing," such as ignore a setter definition, etc. I may not have a perfect understanding of what would leave the "engine in an unstable state however" as Derick mentions on his post about E_RECOVERABLE_ERROR. > -----Original Message----- > From: Anthony Ferrara [mailto:ircmaxell@gmail.com] > Sent: Tuesday, April 24, 2012 10:40 AM > To: Clint Priest > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and references) > > Clint, > > Additionally, one more comment related to the read-only and write-only. I noticed that > you're using E_ERROR for improper access. > Obviously you don't want this to be a warning, as the execution shouldn't continue > because that would be undefined. However, what > about setting it to E_RECOVERABLE_ERROR, so that it can be captured and recovered from...? The > engine wouldn't be in an unstable > state, so if we install an error_handler that throws an exception, there's no reason to > force-terminate the application... > > I guess I'm just adverse to using E_ERROR except for cases where it's literally not > safe to continue (usually because the engine is put in > an inconsistent state)... > > 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 (#60304) next »