Morning Dmitry, > This should be a error. I also think, that "public" might > be omitted, and it should be possible to write "int $bar, $foo"
Omitting public might be nice, but also totally separate, you should be able to omit it for untyped properties too. > You say - C, C++, Java, HHVM, etc - all made worse decision? OK No. C, C++, C#, and Java had a different decision to make. [public] int foo, bar; It is obvious that bar is an int in any of those languages precisely because it necessarily has a type. Why we should jump to the same conclusion, in a system where properties do not necessarily have types is not clear to me. Cheers Joe On Thu, Mar 31, 2016 at 9:58 AM, Dmitry Stogov <dmi...@zend.com> wrote: > > > On 03/31/2016 11:34 AM, Joe Watkins wrote: > > Morning, > > > Given that public is implied for all properties above there > > is a value in having the same rule for type. > > public $bar, int $foo; > > What does this mean? > > If it's not an error, what does this mean ? > > > This should be a error. I also think, that "public" might be omitted, and > it should be possible to write "int $bar, $foo". > > > public $bar, int $foo, $qux; > > If it's an error, why is it an error ? > > Both of these examples are just as ambiguous as > > public int $foo, $bar, $qux; > > > You say - C, C++, Java, HHVM, etc - all made worse decision? OK... > > > Access modifiers are assumed to apply to all declarations in a group, > because that's what grouping is actually for. > > We don't need to make grouping about types, we need to make type > declarations unambiguous. > > > Very strange grouping decision. > At least your opinion is questionable and except for other languages, you > see a number of opponents on @internals. > > Thanks. Dmitry. > > > > > Anyway, in Hack following syntax passes: <https://3v4l.org/3tUu9> > https://3v4l.org/3tUu9 > > Hack does not consider types implicitly nullable. > > <?hh > class Foo { > public int $int = null; > public stdClass $std = null; > } > > things.php:3:10,12: Wrong type hint (Typing[4110]) > things.php:3:10,12: This is an int > things.php:3:21,24: It is incompatible with a nullable type > things.php:4:10,17: Wrong type hint (Typing[4110]) > things.php:4:10,17: This is an object of type stdClass > things.php:4:26,29: It is incompatible with a nullable type > > <?hh > function foo(int $int = null, stdClass $std = null) {} > > things.php:2:18,21: Wrong type hint (Typing[4110]) > things.php:2:14,16: This is an int > things.php:2:25,28: It is incompatible with a nullable type > things.php:2:40,43: Wrong type hint (Typing[4110]) > things.php:2:31,38: This is an object of type stdClass > things.php:2:47,50: It is incompatible with a nullable type > > HHVM doesn't care about types ... we don't compare our type system to that > ... > > Cheers > Joe > > On Wed, Mar 30, 2016 at 11:10 PM, Björn Larsson <bjorn.x.lars...@telia.com > > wrote: > >> 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> >> 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 >> >> > >
