RE: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and references)
| From: | Clint Priest | 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