Re: internals Digest 24 Apr 2012 22:20:08 -0000 Issue 2675

I agree, overloading isset() for properties is somewhat creepy - as that would mean you can no longer rely on isset() to actually work the way it works for any other value. I understand that's actually the intent, but I think this would be confusing - isset() is supposed to behave a certain way depending on the value, and now suddenly it could return completely arbitrary values unrelated to the value of a property, breaking established semantics. As for unset() on the other hand - I feel that this is almost a must, since without it, properties can't fully replace the magic methods. To complete the example from the RFC, it would look like this: class TimePeriod { private $seconds; public property hours { get { return $this->seconds / 3600; } set { $this->seconds = $value * 3600; } } public function __unset($name) { if ($name == 'Hours') { unset($this->seconds); } } } That's pretty awful. For that matter, if __unset() was not implemented, what would happen if you did unset($time->Hours) ? The behavior would be undefined - worst case, nothing would happen at all, which could lead to fun debugging sessions, when you think you're deleting properties and they just stay unchanged. I would suggest making the unset-method optional for properties, and the default behavior for unset($time->Hours) would be $time->Hours=null when no unset-method is implemented. The "readonly" keyword in my opinion is redundant - properties are naturally read-only (or write-only) if you implement only the get or set method, same as any other language. No need to break common language conventions here. RFC looks good though, much better than initial proposals - I like it! :-) - Rasmus > From: Anthony Ferrara <ircmaxell@gmail.com> > To: Clint M Priest <cpriest@zerocue.com> > Cc: "internals@lists.php.net" <internals@lists.php.net> > Date: Tue, 24 Apr 2012 08:56:55 -0400 > Subject: Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and references) > 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()....