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
