For me personally, I would use strict hints for private/protected methods and
weak hints for public methods.
Regards
Thomas
Thomas Bley wrote on 15.01.2015 21:16:
> What about doing both weak and strict with two different syntaxes?
>
> public function __construct(string $name, $age as int, $cuteness as float,
> bool
> $evil) {
>
> string $name // strict
> $age as int // weak
> $cuteness as float // weak
> bool $evil // strict
>
> "as" Syntax is taken from SQL92.
>
> Regards
> Thomas
>
>
> Andrea Faulds wrote on 15.01.2015 20:52:
>
>> Hi Andrey,
>>
>>> On 15 Jan 2015, at 19:20, Andrey Andreev <n...@devilix.net> wrote:
>>>
>>> Consider this badly designed API:
>>>
>>> declare(strict_typehints=TRUE);
>>>
>>> const MODE_APPEND = 0;
>>> const MODE_TRUNCATE = 1;
>>> const MODE_PREPEND = 2;
>>>
>>> function write_file(string $path, int $mode, string $data)
>>> {
>>> // it's quite obvious
>>> }
>>>
>>> Somewhere else, you forget the parameters order ...
>>>
>>> declare(strict_typehints=FALSE);
>>>
>>> $path = '/important/file.dat';
>>> $data = '1 year';
>>> $mode = MODE_APPEND;
>>>
>>> write_file($path, $data, $mode);
>>>
>>> It's a bad example - an awful (and indeed, very much useless) API,
>>> combined with an absent-minded consumer. Yet, it demonstrates how
>>> putting the caller in control *can* cause a disaster.
>>
>> Sure, weak typing is much poorer than strict typing for error checking. Does
>> that mean the user should be prevented from having the choice?
>>
>> Are you simply opposed to the idea of weak types in general?
>>
>>> What I would suggest is the '(type) $weak' vs 'type $strict' syntax
>>> that was already mentioned.
>>>
>>> I've said this before, during the previous RFCs discussions - all of
>>> these proposals will fail, because they all suggest using the 'type
>>> $whatever' syntax and that automatically upsets the "other camp",
>>> whichever it is, but especially if the "other camp" is supporters of
>>> strict typing. That's the moment when they become opposition, while
>>> they could've otherwise not care because it's simply not their
>>> "battle". If both are proposed to co-exist in a clean way (instead of
>>> via a switch), I believe that we'll get substantially more positive
>>> opinions from both sides.
>>
>> Both co-existing doesn’t solve anything, if anything it makes it worse.
>>
>> People who like weak typing don’t want to have to use APIs with strict type
>> hints. If you’re like Zeev and believe it is fundamentally at odds with PHP,
>> you’ll especially dislike it.
>>
>> People who like strict typing don’t want to have to use APIs with weak type
>> hints.
>>
>>>
>>> And to hell with the "consistency" argument. Since when did PHP become
>>> *that* concerned about purity and high consistency levels?
>>
>> I don’t care if PHP is concerned about it. I am concerned about the mess
>> caused by having two or three different argument type checking modes being
>> used
>> within the same function.
>>
>> Marco and S.A.N.:
>>
>>>
>>> On 15 Jan 2015, at 19:45, Marcio Almada <marcio.w...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I would like to call everyone's attention, specially people
>>> contributing directly to this RFC series, to what S.A.N just said:
>>>
>>> > Many developers PHP offers dual syntax:
>>> >
>>> > 1. Strict
>>> > function bar(int $num){}
>>> >
>>> > 2. Lax
>>> > function bar((int) $num){}
>>> >
>>> > Maybe it makes sense to put this option on the ballot if it passes a vote,
>>> > it will be possible to put an end to the discus?
>>>
>>>
>>> This idea has been **so recurrent** and yet systematically ignored by RFC
>>> owners. Why? I think that we need to baby step and try to approve coercive
>>> type declarations first and decide upon a possible stricter type check
>>> later:
>>>
>>> How a bout a reboot of what ircmax...@php.net already started in
>>> https://wiki.php.net/rfc/parameter_type_casting_hints for v0.3?
>>>
>>> PS: Please, let's not fall into the mindset of "if v0.2 is not a good idea
>>> then v0.1 instantly becomes more acceptable", we still have time to try some
>>> alternatives.
>>
>> See what I said above to Andreey.
>>
>> This RFC doesn’t ignore having two syntaxes. It sets out to avoid the
>> nightmare that two syntaxes would cause.
>>
>> Thanks.
>>
>> --
>> Andrea Faulds
>> http://ajf.me/
>>
>>
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
