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
