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