On 03/31/2016 03:40 PM, Joe Watkins wrote:
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.
Right. We may use "var $a, $b;".
> 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.
Just not to confuse programmers with uncommon grouping behavior.
Thanks. Dmitry.
Cheers
Joe
On Thu, Mar 31, 2016 at 9:58 AM, Dmitry Stogov <dmi...@zend.com
<mailto: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
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
