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
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 <mailto: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
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
