Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Property Accessors v1.2 : Extra shorthand declaration »

[RFC] Property Accessors v1.2 : Extra shorthand declaration

php.internals

Clint M Priest

13 years ago
I'm opening up several new threads to get discussion going on the remaining "being debated" categories referenced in this 1.1 -> 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests ------------------------------------------------------------------------ *Extra shorthand declaration* Allow extra short declaration of an accessor: class TimePeriod { public DateTime $date; } /* Would be equivalent to this */ class TimePeriod { public $date { get() { return $this->date; } set(DateTime $value) { $this->date = $value;} } } ------------------------------------------------------------------------ Thoughts?
-- -Clint

Jazzer Dane

13 years ago
Is the only intended benefit behind this proposal the ability to seamlessly extend a seemingly normal property as an accessor? On Fri, Oct 26, 2012 at 3:43 AM, Clint Priest <cpriest@zerocue.com> wrote:

Stas Malyshev

13 years ago
Hi!
> /* Would be equivalent to this */ > > class TimePeriod { > public $date { > get() { return $this->date; } > set(DateTime $value) { $this->date = $value;} > } > }
I don't think this has a use case and this encourages mixing variables with properties (which I'm not sure is a very good idea) and writing slower and more complicated code which doesn't actually do any additional work. I'd rather not encourage it. If you want it - fine, implement it, but I don't think supporting it is good. Also, "get() { return $this->date; }" implies there is a thing called "$this->date" which is not the property itself. So what is it? Should there be additional "public $date;" declaration in your code? Is it implied that property definition also creates a variable inside class automatically - I was under expression this does not happen, and nothing in the RFC implies it. Should it be $this->__date maybe like in "automatic accessors" part of the RFC?
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Clint M Priest

13 years ago
On 10/26/2012 9:39 AM, Stas Malyshev wrote:
> Hi! > >> /* Would be equivalent to this */ >> >> class TimePeriod { >> public $date { >> get() { return $this->date; } >> set(DateTime $value) { $this->date = $value;} >> } >> } > I don't think this has a use case and this encourages mixing variables > with properties (which I'm not sure is a very good idea) and writing > slower and more complicated code which doesn't actually do any > additional work. I'd rather not encourage it. If you want it - fine, > implement it, but I don't think supporting it is good.
I would agree that it should not be in here, AFAIK only Nikita was pushing for this... anyone else want to fight to have this functionality?
> Also, "get() { return $this->date; }" implies there is a thing called > "$this->date" which is not the property itself. So what is it? Should > there be additional "public $date;" declaration in your code? Is it > implied that property definition also creates a variable inside class > automatically - I was under expression this does not happen, and nothing > in the RFC implies it. Should it be $this->__date maybe like in > "automatic accessors" part of the RFC?
This is related to accessors shadowing properties, if that's the case then $this->date would retrieve an actual property named date (and since it's shadowed by the accessor it could never be accessed from outside the accessor. See the shadowing thread.
-- -Clint

Levi Morrison

13 years ago
> ------------------------------------------------------------------------ > *Extra shorthand declaration* > > Allow extra short declaration of an accessor: > > class TimePeriod { > public DateTime $date; > } > > /* Would be equivalent to this */ > > class TimePeriod { > public $date { > get() { return $this->date; } > set(DateTime $value) { $this->date = $value;} > } > }
This is lovely. Full support from me. I just have one question: can we drop `public`? Default visibility in methods is public, so maybe we can drop it when using type-hinted properties? Just an idea; no worries if it needs to stay.

Stas Malyshev

13 years ago
Hi!
> I just have one question: can we drop `public`? Default visibility in
We already had var, it didn't prove a good idea. PHP is explicit for a reason, to be clear.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Larry Garfield

13 years ago
On 10/26/2012 05:43 AM, Clint Priest wrote:
> I'm opening up several new threads to get discussion going on the > remaining "being debated" categories referenced in this 1.1 -> 1.2 > change spec: > https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests > > > ------------------------------------------------------------------------ > *Extra shorthand declaration* > > Allow extra short declaration of an accessor: > > class TimePeriod { > public DateTime $date; > } > > /* Would be equivalent to this */ > > class TimePeriod { > public $date { > get() { return $this->date; } > set(DateTime $value) { $this->date = $value;} > } > } > > ------------------------------------------------------------------------ > Thoughts? >
My knee-jerk response is that I'd love to be able to do public DateTime $date; it's nicely self-documenting and gives me very simple type safety (and therefore a clear and useful error thrown in my face, rather than a mystery bug later). That said, I think that goes back to my mental model question in my previous post, and I can't fully endorse this without knowing my mental model. --Larry Gafield