On 19/11/2016 14:04, Rasmus Schultz wrote:
lack of features and consistency [...] where these features were engineered into the language from the design stage, rather than being added on a bit at a time.
I think the consistency and "engineered in" parts of this are more important than people give them credit for. Adding type hints to a dynamic language is not a trivial thing; what do those type hints actually *mean*?
He actually had something like "public int $id" in a class-declaration on his screen, and was genuinely confused - he simply assumed that would work
What did he expect that declaration to do? Did he expect his program not to compile if he wrote some code that assigned a string? Did he expect to have to run a static analysis tool to detect errors? Did he expect the run-time to insert an assertion on every assignment and raise a runtime error? Did he expect this to happen even in production, or only in a development-only "checked" mode? All of these are possible behaviours, implemented in other languages.
I've written some of my thoughts on how it *could* work in this blog post: http://rwec.co.uk/q/php-type-system
Before we add type hints anywhere else in the language, I think we need to think about what we are actually working towards. Otherwise, we're going to end up with a mess of inconsistent rules because each set of type hints was added separately with slightly different semantics and caveats.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
