Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84809
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAB6YZuzEy4064OUEc4bLqqUXFGvNYsrcDkKf6OfB-G54s0KeZw@mail.gmail.com>
References: <CAPKwhws-o7Z-k9zwDW9qPEMw=vKaNP9YM1yXtWM+wR5qjwBzGQ@mail.gmail.com>
	<CAB6YZuzEy4064OUEc4bLqqUXFGvNYsrcDkKf6OfB-G54s0KeZw@mail.gmail.com>
Date: Sun, 15 Mar 2015 08:56:04 +0000
Message-ID: <CAPwsocH5ML44it43J=qm=FZPnqun0jSjmWip67tQVUWTuihdVw@mail.gmail.com>
To: =?UTF-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>
Cc: Scott Arciszewski <scott@arciszewski.me>, 
	"inter >> PHP internals" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0162832658ef7c05114fe7b1
Subject: Re: [PHP-DEV] Re: A plea for unity on scalar types
From: leight@gmail.com (Leigh)

--089e0162832658ef7c05114fe7b1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 15 March 2015 at 08:42, Pavel Kou=C5=99il <pajousek@gmail.com> wrote:

> 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 declaration is turned on with code. This is no different to changing an
ini setting with code, except that it can't be configured globally in
advance.

Existing code is unaffected. I'm not sure where your "not easily
revertible" argument is grounded. It's incredibly easy to add/remove
declarations at the top of a file.

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.
>

Pure FUD. Sorry but there is no evidence to back this up.

PHP will IMHO never be strongly-typed by default.


Probably.


> 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?).


You think the best approach is to progressively and continually break
working code between versions? How is this approach acceptable ever?


> 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.
>

No, they would never reach agreement.

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.


Apologies again, but I think you don't really understand what is being
proposed in this RFC. Proponents of strict typing get exactly what they
want, they can develop their library or entire project in strict mode if
they want, and if someone wants to use this project or library, but
themselves want to use weak mode, _nothing breaks_.

--089e0162832658ef7c05114fe7b1--