Hi Andrea,
On Wed, Feb 4, 2015 at 8:21 PM, Andrea Faulds <a...@ajf.me> wrote:
> Hi again,
>
>> On 4 Feb 2015, at 11:15, Andrey Andreev <n...@devilix.net> wrote:
>>
>> On Wed, Feb 4, 2015 at 1:02 PM, Florian Margaine <flor...@margaine.com>
>> wrote:
>>> Hi Leigh,
>>>
>>> Le 4 févr. 2015 11:50, "Leigh" <lei...@gmail.com> a écrit :
>>>>
>>>> What was wrong with:
>>>>
>>>> function x(int $y, string $z) { // strict
>>>> function x((int) $y, (string) $z) { // casting
>>>>
>>>> This was the best suggestion I've seen that covers the requirements of
>>>> both camps, and is still very clear how data is going to be handled.
>>>>
>>>> Authors who want their APIs to adhered to strictly can do that,
>>>> authors who want to accept anything and have it end up as their
>>>> desired type can do that too.
>>>
>>> Because it is then the callee who decides, not the caller, whether or not
>>> he wants strict typing.
>>>
>>
>> ... and apparently, this is the root of all evil. :)
>
> It’s not “the root of all evil". But the two-syntax approach has
> disadvantages I’ve elaborated numerous times.
>
> It shifts the choice to the callee, not the caller. This means existing
> applications are broken if strict hints are added to existing libraries. It
> means that programmers will have to deal with two different systems,
> simultaneously, in the same file or function or method, because one API uses
> (int) and the other uses int. It means that if the API author decides to have
> weak types, you are prevented by the language from having the benefits of
> strict typing, even if you want them. It also has a syntax issue: (int) looks
> like an explicit cast, yet what is usually proposed doesn’t something
> similar. There’s also the consistency issue in that we’d have to support real
> for consistency with (real), since T_DOUBLE_CAST is a token. It means that
> internal functions could now also use strict hints - or if they can’t, we
> have a consistency issue. It means beginners, and people who don’t like
> strict types, now have to deal with strict types in their code, despite PHP
> always having been a weakly-typed, beginner-friendly language. And so on, and
> so forth.
>
> The current RFC deliberately does not propose this because I think it causes
> more problems then it solves.
>
>> I am baffled by how the two-syntaxes suggestion is always so easily
>> dismissed by that argument. I'd argue that most people who support the
>> current proposal don't fully understand what declare(strict_type=1)
>> really does.
>
> Well, *I* understand what it does.
That's an own goal (in football/soccer terms), you know. ;)
> I’ve used it. It worked really, fantastically well… better than I expected it
> to. It provided benefits that the two-syntax suggestion wouldn’t have. It
> provided benefits that just strict hints wouldn’t have. It provided benefits
> that just weak hints wouldn’t have.
>
>> As I've previously said - putting the caller in control
>> (and really the caller, not in a per-file context) makes it a
>> debugging tool, not support for strict typing.
>
> What’s the difference between “per-file” and “really the caller”? The RFC
> *does* allow you to use declare() blocks if you really want to.
>
> Also, type hints are mostly a debugging tool anyway. They’re a tool for
> catching errors early, and to enable better documentation. That’s all that
> they do.
>
Yeah, you've said that numerous times ... almost as much as I have
disagreed with your arguments.
I didn't want to turn this thread into a re-iteration of the RFC
discussion one. I'm just completely surprised how relentlessly all
suggestions about two syntaxes have been waved off by a callee vs
caller argument like it's a golden rule or something ... it's not, you
just don't like the other approach.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
