Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106310
MIME-Version: 1.0
References: <CAF+90c_Ctjja=8fR-uBWL1wDxZge771yMujMhaR_R2seKXciYw@mail.gmail.com>
 <CAF+90c8JhV6-aQrsvW8u_xGB-wHmyObEU1Chd64J+x3tkKogQQ@mail.gmail.com> <0143be10-1dff-58dc-818b-23e76345406f@gmail.com>
In-Reply-To: <0143be10-1dff-58dc-818b-23e76345406f@gmail.com>
Date: Sun, 28 Jul 2019 18:56:24 +0100
Message-ID: <CA+kxMuRQRemMz9KBVeB3k=4jnbKrofRN+Wo_2jRr=n0rt4+=SA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
From: Danack@basereality.com (Dan Ackroyd)

On Sun, 28 Jul 2019 at 04:17, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>
> We've decided not to do INI options to change language behavior,...
> because they are - especially when applying to more than local
> file - essentially low-grade INI options

I don't agree. What's being proposed are not low-grade INI options.

The problems with ini settings is that:
* Different libraries could require different settings.
* There was no way to manage the settings individually per library.

Those problems do not apply to the proposed RFC.

As we've seen with the declare for strict types, libraries that want
to have strict mode, and libraries that want to have more type
juggling, are perfectly fine to live alongside each other, and can be
used just fine.

> I think it's a wrong way to make semantics of the language to be
> different in different libraries.

I can't agree.

I look at the success of how strict types was brought in, in a way
that allowed for zero breaking changes for existing code, and think it
was a massively successful way of improving the language without
causing problems.

I can't understand why someone would make the argument that evolving
the language like this is a bad thing.

> This looks like potential to create an environment that is
> very hard to navigate and keep straight which of the options
> is in play for each peace of code.

You're saying very negative things about a feature you would not have to use.

There have been multiple problems/features over the years that would
have been more solvable is we had this RFC implemented.

It's fine that you're not convinced that this is a great idea, but
please can you stop making the argument that because you don't want to
use a feature, no-one should be allowed to use it?

cheers
Dan
Ack