Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112981
Date: Mon, 25 Jan 2021 14:03:47 +0100
To: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <08f91596a4219b8411dab06450b8bf51b4e84d16@hey.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_600ec1b341dbb_215e3020877c5";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Proposal: Automatically inheriting functions from parent namespaces
From: samuel.stancl@hey.com (=?UTF-8?B?U2FtdWVsIMWgdGFuY2w=?=)

----==_mimepart_600ec1b341dbb_215e3020877c5
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think it would be useful if namespaced *functions* automatically=0D
propagated to all child namespaces as well.=0D
=0D
An example use case of this would be packages having their own helpers=0D=

like this:=0D
=0D
namespace MyPackage {=0D
=C2=A0 =C2=A0 function foo() {}=0D
=C2=A0 =C2=A0 function bar() {}=0D
}=0D
=0D
And being able to use them in MyPackage\Commands, MyPackage\Fields, ...=0D=

as if they were global functions.=0D
=0D
The benefit of this is that packages could safely add helpers functions=0D=

without risking conflicts and having to do awkward function_exists()=0D
checks (which can break things easily). And there would be no overhead=0D=

of having to import functions, since that seems to be a pretty obsolete=0D=

practice nowadays with only classes being imported in most major=0D
projects.=0D
=0D
Which means that this could revive the practice of namespacing functions=0D=

while solving the problem of conflicting global helpers from multiple=0D
dependencies.=0D
=0D
And of course, this is a breaking change. Though I'm not sure how big of=0D=

a problem upgrading would be, since having multiple functions with the=0D=

same name, but in different namespaces, seems like a pretty rare thing.=0D=

=0D
Thanks,=0D
Samuel=0D

----==_mimepart_600ec1b341dbb_215e3020877c5--