On 18 February 2015 at 20:44, Anthony Ferrara <ircmax...@gmail.com> wrote:
> Dear Internals,
>
> Since the resignation of Andrea, the mixed-mode type hint (called
> declaration in the proposal) proposal has been left abandoned.
> Considering that the ending votes were 67/34 (66.3%) with several
> no-votes being only due to reasonably minor issues with the proposal,
> I would like to re-propose her RFC with three minor modifications:
>
> 1. declare(strict_types=1) (if used) is required to be the first
> instruction in the file only. No other usages allowed.
> 2. declare(strict_types=1) {} (block mode) is specifically disallowed.
> 3. int typed variables can resolve a parameter type of float So
> calling requiresAFloat(10) will work even in strict mode.
>
> As this topic has and is being discussed to death, I have put a very
> large "discussion points" section:
> https://wiki.php.net/rfc/scalar_type_hints_v5#discussion_points
>
> I would kindly ask, before replying that you check to see if your
> question is answered in that list.
General comments from me, as a radical strictist. No need to reply and
tell me I'm "wrong", these are my opinions.
> Internal Functions Like ceil() Return Unexpected Types
My opinion is that functions should return sane types for their
intended purpose, and functions that do not should be "fixed".
> Integers Should Be Accepted For Strict float Arguments
> Int->Float Exception Makes Strict Mode "Flawed"
My opinion is that strict should mean strict.
> Static Analysis Is Possible With Weak Declarations
The advocacy of allowing `accepts_float(returns_int());` doesn't help
the cause of static analysers in strict mode.
> Why Not Add Support For Null?
I agree a null type is pointless, however I would like to raise the
discussion point of existing hinted optional parameters being allowed
a default of null. i.e. fn(Obj $o = null) {}
Do you think this is acceptable for any other types? I can only think
of it being useful if resource and a generic object type are added.
but others may disagree. (Ideally the resource type will go away over
time and will be replaced with objects like GMP anyway :))
Still no mention of a way to enable strict by default. So lets try
some different rationale. If I personally want to develop in strict
mode, I can do that with this proposal, I can add a declare to the top
of every file and be as strict as I like. However not everyone else is
going to want to use my code in strict mode, so they will have to go
and remove some/all of those strict declarations. (Lets take callbacks
being evaluated in the context they are called rather than the one
they are created in). I would like a way of enabling strict by
default, immutable to scripts so that users cannot be forced into this
mode, and lets the radicals and the weaklings* play together in
harmony.
For the rest of the RFC, I either agree with or have no strong
opinions about the points raised.
*it's a joke you guys.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
