>
> Forcing people to specify a visibility for properties and not for methods
> would add yet another inconsistency in the language.
>
That's a really good point. However, I think we currently have a different
inconsistency: declaring functions without explicit visibility is possible
without needing an extra (and redundant) keyword.
The inconsistency you mention could easily be solved by a future RFC. We
could:
1. Require visibility for class methods.
2. Allow declaring properties without using any keywords.
3. Use some other approach?
I don't think we necessarily need to choose an option at this time (or
perhaps ever).
> #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?
>
Correct. This RFC only targets the deprecation and removal of T_VAR.
> 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".
>
I disagree - this RFC does not prevent anyone from declaring properties,
you just need to explicitly declare the visibility.
> I'm generally in favour of not having duplicated ways of doing the exact
> same thing.
> I'm generally in favour of not introducing (uneeded) BC issues.
> I'm not convinced that the number of people that will benefit the
> uniqueness of declaring a variable would be greater than the one suffering
> upgrade issues.
>
I disagree on the third point - I think the automated upgrade process is
literally the second-easiest upgrade possible (#1 would be no changes
required). Nevertheless, I truly appreciate you considering and weighing
the different aspects of this proposal. I'm hoping others will take a
similar approach in deciding whether they support this RFC.
Thanks for your feedback!
Colin
>
