Den 2016-03-14 kl. 19:14, skrev Colin O'Dell:
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
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
On 14 Mar 2016 6:14 p.m., "Colin O'Dell" wrote:
>
> >
> > 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.
Yup, agree with this. In my opinion, I'd like to
>
> 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
Le jeu. 10 mars 2016 à 18:15, Colin O'Dell a écrit :
> Hello all,
>
> I have completed my initial draft of the RFC to deprecate "var" in favor of
> "public": https://wiki.php.net/rfc/var_deprecation
>
> I would greatly appreciate any feedback on this RFC, especially with
>
> I'm still on the fence about this, but here's a patch for it:
> https://github.com/php/php-src/compare/master...tpunt:deprecate-var
Thank you so much Thomas! I have added your patch to the RFC. I really
appreciate you taking the time to implement this.
Regards,
Colin
Hi!
> Hello all,
>
> I have completed my initial draft of the RFC to deprecate "var" in favor of
> "public": https://wiki.php.net/rfc/var_deprecation
>
> I would greatly appreciate any feedback on this RFC, especially with the
> following:
>
> - Ensuring that all major arguments for & against
Jakub Kubíček wrote on 11/03/2016 10:03:
From the RFC:
var is therefore a limited subset of public.
No, this is wrong. `var` was here much much longer than `public`, therefore
`var` is not a subset of public, but rather `public` is _an extension_ of
`var`.
This is like arguing based on
2016-03-11 12:03 GMT+02:00 Jakub Kubíček :
> From the RFC:
>
>
> > var is therefore a limited subset of public.
>
>
> No, this is wrong. `var` was here much much longer than `public`, therefore
> `var` is not a subset of public, but rather `public` is _an extension_ of
>
On 11 March 2016 at 10:03, Jakub Kubíček wrote:
>
> - `var` can semantically also represent an internal dependency, as I have
> described earlier
An internal property should be `private`. The use of `var` in the specific
project you referenced earlier should only be
>From the RFC:
> var is therefore a limited subset of public.
No, this is wrong. `var` was here much much longer than `public`, therefore
`var` is not a subset of public, but rather `public` is _an extension_ of
`var`. The keyword `var` is also unique for it's semantics in the later
versions
Hi!
On Fri, Mar 11, 2016 at 2:14 AM, Colin O'Dell wrote:
> I have completed my initial draft of the RFC to deprecate "var" in favor of
> "public": https://wiki.php.net/rfc/var_deprecation
>
> I would greatly appreciate any feedback on this RFC, especially with the
>
Hi!
> I have completed my initial draft of the RFC to deprecate "var" in favor of
> "public": https://wiki.php.net/rfc/var_deprecation
As I already stated here, I think this is needless change which only
creates BC problems and does not add anything to the language. The RFC
incorrectly claims
Colin O'Dell wrote on 10/03/2016 17:14:
Hello all,
I have completed my initial draft of the RFC to deprecate "var" in favor of
"public": https://wiki.php.net/rfc/var_deprecation
Hi Colin,
Thanks for a very thorough RFC, particularly in clearly expressing the
arguments for and against,
Hello all,
I have completed my initial draft of the RFC to deprecate "var" in favor of
"public": https://wiki.php.net/rfc/var_deprecation
I would greatly appreciate any feedback on this RFC, especially with the
following:
- Ensuring that all major arguments for & against have been documented.
-
15 matches
Mail list logo