Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96187
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender)
To: internals@lists.php.net
References: <CAF+90c-4CuwgJgBPXbYvEJ0W6k41CfP94Xs-ZyNkUzrecbTzvg@mail.gmail.com>
Message-ID: <fc713c0b-bb60-2905-d1e2-b60d13f59649@gmail.com>
Date: Sun, 2 Oct 2016 19:30:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-4CuwgJgBPXbYvEJ0W6k41CfP94Xs-ZyNkUzrecbTzvg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Namespace-scoped declares
From: rowan.collins@gmail.com (Rowan Collins)

On 23/09/2016 12:41, Nikita Popov wrote:
> Hi internals!
>
> I'd like to propose the ability of specifying declare directives like
> "strict_types" at the namespace level.
>
> The broader context of this proposal is to provide a simple and usable
> mechanism that will allow developers to opt-in to stricter language
> semantics on a per-library (or more specifically, per-namespace) basis,
> thus alleviating backwards compatibility and library interoperability
> concerns for such changes.

I'm with others on not liking the idea of adding a new set of "at a 
distance" settings into the language. If distributing a package of PHP 
code was like distributing a compiled library, then it might make more 
sense, but even then we could all end up learning multiple variants of 
the same language.

It's interesting that you pick as your example preventing dynamic object 
properties. That's definitely a useful option, but it turns out it can 
already be done, on a class by class basis. I've put together a quick 
library here: https://github.com/IMSoP/php-strict It lets you write this:

class SomeModel {
     use \IMSoP\Strict\Properties;
     public $someProperty;
}

To me, that seems a lot clearer than this:

namespace Some\Project;
class SomeModel {
     public $someProperty;
}

Where "Some\Project" happens to have had a compiler option activated 
that injects invisible code to make the class behave more strictly.

If we did want to build such a switch into the language, declaring it 
inside the class in a similar way to using a trait would seem pretty 
sensible to me.


> namespace Symfony\Whatever\Namespace;
> function strlen($str) {
>      return \strlen($str) + 1;
> }
> // Repeat for a few more namespaces.
>
> This will end up hijacking uses of the strlen() function within the Symfony
> codebase due to the way the global namespace fallback works.


Well, as the recent autoloading discussion showed, that global namespace 
fallback is not without its problems. And it looks like 7.0 has finally 
removed the ability to redefine "true" and "false" as namespace 
constants, although I'm not sure if this was just a side-effect of the 
phpng work https://3v4l.org/S2AFZ


Regards,

-- 
Rowan Collins
[IMSoP]