Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94216
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
References: <CAL=_i_ndnBUEHUcNxPJxxkhZ70jM4xE-xkjuftWpHHNSKMchOA@mail.gmail.com>
 <BY2PR0201MB1784884D794E3FF56E08D124BF500@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAGa2bXY+xKNRn+Z28QJOkLrdWunNR7QcNn8XXuHDp2ws4exXcQ@mail.gmail.com>
 <CADqTB_h_TRUJqezT-zan6WWXAcZvnD9DPwY1H=ZH+RjtYE8PSA@mail.gmail.com>
 <CAL=_i_nga8CO9qrJ-KAa8UKhSBudBj-SerFHLAU175SRQsbW+g@mail.gmail.com>
 <CABdc3Wo8qOf+sTRXGTHDKrLijGJj5aUQZqJhe3byn1-F4Ev1tQ@mail.gmail.com>
 <576A6165.8090904@lsces.co.uk>
 <CADqTB_gmAHEO=NUxzqtv9iYs8ovzM2432OFoEXOb0yuf3SrrSA@mail.gmail.com>
 <20376416-aa04-766d-6178-189d1a088b01@gmail.com>
 <CADqTB_gxucSBAr+DGR059Zuo24qbfdAhcUM3mwcOxaLwU4FK7g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Message-ID: <411d306c-b42f-4ff4-8280-99ff357c94a1@gmail.com>
Date: Wed, 22 Jun 2016 22:21:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <CADqTB_gxucSBAr+DGR059Zuo24qbfdAhcUM3mwcOxaLwU4FK7g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: rowan.collins@gmail.com (Rowan Collins)

On 22/06/2016 20:06, Rasmus Schultz wrote:
> With Dart, you have a choice - you can actually toggle whether or no
> type-checks should be performed at run-time. It's probably the best of
> those two references, if you're looking for inspiration for PHP.

Ooh, that sounds interesting, I'll have to read up on it. :)


> In PHP, every type-check is performed at run-time, and type-hints are
> reflected - that's extremely important, and something Hack got
> horribly wrong, as the type-hints they introduced are merely
> annotations, with no run-time footprint, checked only by a static
> analyzer that runs in the background; completely inconsistent with
> type-checks in PHP.

Hm, that's a good point, I hadn't really thought about reflection. The 
general direction of my thoughts was to separate the concepts of "type" 
and "type constraint" - e.g. no value has the type "callable", but you 
can already constrain a parameter with the "callable" constraint. That 
fits nicely with things like union types, range / subset types, etc. But 
the more complex those constraints could be, the harder they'd be to 
represent with reflection...


>> Except that this proposal doesn't actually make the language consistently
>> type-checked. It adds a few more special cases where you can use type hints,
>> with slightly different behaviour.
> That's not quite true.
>
> With the addition of property type-hints, the public surface through
> which you interact with objects would consistently support type-hints
> - so at least that makes object interactions and class design a lot
> more predictable.

I guess it's more a matter of opinion than truth. :) To me, a consistent 
typing system would be one that allows me to put type constraints 
wherever I have values. For instance, the current RFC excludes static 
properties, which as a user I consider to be close relatives of object 
properties, but to the engine are apparently more like plain variables. 
That's the kind of inconsistency that frustrates me, and makes the 
feature feel "half-baked", especially given that filling in the gaps is 
left as a "maybe, one day" rather than a "coming soon".


> But at least we're finally there as far as objects, which in PHP is
> probably the most important thing, as that's almost exclusively the
> means by which we share code.

I'm not really convinced by this. I think the type system should be a 
feature of every part of the language, not just where it's convenient to 
fit it into the engine.


>>> Indeed, "gradual typing" as defined by Jeremy Siek only really makes sense
>>> in the context of static analysis.
> Quoting Jeremy Siek: "Gradual typing allows software developers to
> choose either type paradigm as appropriate, from within a single
> language" - to me, that's the important thing about gradually-typed
> languages.

Absolutely, we can import the goals of gradual typing. I just meant that 
the specific mechanism he described, of treating the "Any" type as 
"consistent with" every constraint, is a solution for writing static 
analysis tools, and doesn't help at run time, because there's never 
actually a value of the "Any" type.


>> Taking lots of little steps "towards" a goal that we've never even properly
>> defined is exactly what leads to *inconsistency* in the language.
> I don't disagree with that, and I think that's a large part of PHP's problems.
>
> But, on the other hand, we started down the road to gradual typing
> when we started adding type-hints - whether we knew what we were doing
> at the time or not, the next logical step down that road is property
> type-hints, which will at least clear up the number one biggest
> inconsistency as far as object and class design goes.

But we haven't ever decided what that road is, so how can we know what 
the next step is? What if we realise that the way we've implemented 
typed properties is completely at odds with the way we want to implement 
typed locals?


>> I think a number of people are not "anti-type-hints", they just don't agree
>> with this particular implementation.
> Very possible, and they may be right - but I really hope these people
> are doing something to help solve the problem, rather than simply
> killing the idea and offering no alternative.

I agree, but I'd urge you to practice what you preach - don't despair 
that this vote didn't pass, engage with the people who voted against it, 
and work out how to make a proposal they'll approve. There's already a 
majority of voters, just not the required super-majority, so I think 
it's pretty clear that there's an appetite for the idea, if pushed in 
the right direction.

Regards,

-- 
Rowan Collins
[IMSoP]