Re: [RFC Discussion] Typed Properties

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 <dmitry@zend.com <mailto:dmitry@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.larsson@telia.com <mailto:bjorn.x.larsson@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