Re: [RFC Discussion] Typed Properties

Den 2016-03-30 kl. 05:16, skrev Joe Watkins:

Morning Dmitry,

1) static typed properties are prohibited. why?

Feels like that's a separate feature, static properties are as good as makes no difference, global variables. Instance properties, the engine has good control over their manipulation, for static properties it doesn't, it's not impossible, but feels separate. Good that it's clarified in the RFC since one could easily

believe that it's possible to set type for a static property.

2) The handling of multiple properties in the same declaration statement

is inconsistent. This feels consistent to me .. in other languages where the type is required, it makes sense to assume the type is implied. In a language where the type is optional, public int $foo, $bar; feels ambiguous to me. Given that public is implied for all properties above there

is a value in having the same rule for type.

3) We already have nullable arguments without any special syntax. We

should reuse the similar approach for properties. Making properties implicitly nullable defeats the object of trying to provide type safety. Null is never a valid value for a typed property, if it were, you would never be sure of the type of variable you are getting, and would have to litter your code with is_null checks. Maybe good to clarify difference towards default parameters?

Anyway, in Hack following syntax passes: https://3v4l.org/3tUu9

I think it might be better to implicitly initialize them according to

type (if default value is not provided): bool by false, int by 0, double by 0.0, string by "" (interned), array by [] (immutable), objects by NULL (always nullable). Definitely not, lying about the default value isn't a good idea. There are times when 0 is as valid as 1, or any other value for an int. If you have declared that you know the type of the property, and you write code that accesses that property before there is any possible chance you have set the property, that's a programming error. We should not hide that error with a default value, or by allowing the engine to return null. Don't have a strong opinion on this one, can see both views.

Maybe a bit affected by programming in Java recently, having a slightly more positive attitude towards default values ;-) Regards //Björn Larsson