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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
