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
Is the only intended benefit behind this proposal the ability to seamlessly
extend a seemingly normal property as an accessor?
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-requestshttps://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
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
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
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.
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
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