Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84808
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPKwhws-o7Z-k9zwDW9qPEMw=vKaNP9YM1yXtWM+wR5qjwBzGQ@mail.gmail.com>
References: <CAPKwhws-o7Z-k9zwDW9qPEMw=vKaNP9YM1yXtWM+wR5qjwBzGQ@mail.gmail.com>
Date: Sun, 15 Mar 2015 09:42:29 +0100
Message-ID: <CAB6YZuzEy4064OUEc4bLqqUXFGvNYsrcDkKf6OfB-G54s0KeZw@mail.gmail.com>
To: Scott Arciszewski <scott@arciszewski.me>
Cc: "inter >> PHP internals" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: A plea for unity on scalar types
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

On Fri, Mar 13, 2015 at 8:51 PM, Scott Arciszewski <scott@arciszewski.me> w=
rote:
>  Pavel_Kou=C5=99il wrote:
>
>> - It is a "setting" that changes the language's behavior; I don't
>> think that it matters whether or not it would be an INI setting or the
>> declare() one, because both of them are bad.
>>
>> It allows people who want strict typing to declare it on a per-PHP-file
> basis. An INI setting cannot offer this guarantee. This is required if we=
ak
> and strict are to be both supported.
>
>> - It does not "unite different usages of PHP into a single group"; it
>> does exactly the opposite, splitting PHP usage into TWO groups.
>>
>> It also allows the two groups to work together rather than forking PHP
> into separate languages: PHPstrict and PHPweak.
>
>> - Once this dual mode would be introduced to PHP, there would probably
>> be no way of removing it later without massive BC break, once most
>> people would realize that it is really awful to have it in the
>> language.
>>
>> What is "really awful" about this? Moving forward, everything could move
> towards strict typing. I could see PHP 8 or 9 having strict be the defaul=
t,
> if everyone wanted that. And then the declare() being deprecated and
> removed as major versions increase.
>
> Scott

Hello,

I'm sorry, I totally overlooked your email, so I'm replying with a little d=
elay.

Sure, per-file is better than ini setting, but better doesn't mean
good (because it is still a pretty bad approach). The ini setting at
least has the option to be turned off in code once everyone realizes
it was a bad idea (register_globals via htaccess, for instance), but
PHP would be stuck with the declare for a long time - this is not an
easily revertable change, once PHP ships with it.

The two groups (people who want strong typing and weak typing) will
not work *together* though. And it will be a nightmare for everyone
working on multiple projects from mulitple clients or so.

PHP will IMHO never be strongly-typed by default. It would break BC so
much it's not just possible. The best approach to have some reasonable
type rules is to progressively "strenghten" the rules (as Zeev's RFC
tried to do so, but he probably did two steps in one RFC and that's
what people dislike about it?). I think that PHP's type system would
get to some "equilibrium" by this - people wanting stronger typing
would tried to introduce it and people wanting weaker one would
balance it and eventually there could be a point on which both sides
could agree on.

I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the
RFC being good for the userland developers in the long run.

Regards
Pavel Kouril