On 3/14/2016 7:26 PM, James Titcumb wrote: > Yup, agree with this. In my opinion, I'd like to see two birds with one > stone, but a separate RFC is acceptable I suppose. The only risk is one > change getting voted in and not the other, leaving an even worse > inconsistency IMO. I think this RFC should be all or nothing: require > visibility for both methods and properties, or do not require anything. >
+1, but ...
On 3/14/2016 6:34 PM, Patrick ALLAERT wrote:
> Besides that, there isn't 2 ways for declaring a property, but (at
least) 3:
>
> #1
> class Example {
> var $foo;
> }
>
> #2
> class Example {
> public $foo;
> }
>
> #3
> class Example {
> public function __construct() {
> $this->foo = null;
> }
> }
>
> If I understand this RFC, example #1 is handled by it, but not #3.
> Using #1 would emit a deprecation notice, but #3 wouldn't?
> As far as I am concerned, I think it is still better to declare the
> properties rather than not and this RFC would (somehow) favour not
> declaring them at all than doing so with "var".
>
... #3 is a different language feature of PHP: dynamic assignment of
properties to objects. Userland code does not and should not care if the
internals code creates these dynamic properties with *var* or *public*
or *very-special-internals-visibility-modifier*. ;)
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
