# Clarifying the resolution rules

- Thread: https://externals.io/message/41437
- Original archive: https://news-web.php.net/php.internals/41437
- Started by Stan Vassilev | FM on 2008-10-27T11:36:55+00:00
- Messages: 10
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #41437 — Stan Vassilev | FM — 2008-10-27T11:36:55+00:00

URL: https://externals.io/message/41437#41437

Hi,


Now that we have a separator, it's time to clarify what happened to the resolution order for functions and classes, which if I read Greg's messages, is still not clearly defined.

1) I think we've established that autoloading + fallback for classes is unworkable, as it either causes excessive autoload triggering, or alternatively allows internal classes to override unloaded but to-be-autoloaded namespaced classes. Then why is it still under consideration?

2) Making the backslash optional for internal functions means popular drop-in replacements for internal functions and extensions in global space, which work today, will break in a namespace, examples: libcurlemu. Also check any comments on PECL functions on php.net, and you'll see a myriad of drop-in replacements people use today.

Also, for those who want to automatically convert their internal functions to backslash prefix for use in namespaces, you can use this quick snippet I wrote (works in 5.2.x too):

http://pastebin.com/f13125acd

I don't make guarantees it's perfect, but it can be improved and given to people as a porting aid.

Opinions about how disruptive a mandatory backslash for global symbols *in namespaces* would be, are welcome. Keep in mind that making the backslash optional will lead to code breakage (such as for above drop-in replacements, class autoloading etc.) and slower performance (runtime resolution of function calls).

Think of it as file paths. When you're inside a directory you need to prefix your path with "/" (eg "\") to refer to the root, but you don't need to do that when you're in the root directory.

Regards,
Stan Vassilev

---

## #41496 — Josh — 2008-10-28T02:58:18+00:00

URL: https://externals.io/message/41437#41496 · In reply to: #41437

Hey,

I think that using \ to prefix global symbols in namespaces would be
quite dumb. It would feel counter-intuitive because then if your
coding you would need to think to yourself, "am I in a namespace?",
thus increasing the chance for simple errors. It would be incedibly
annoying when writing php libraries, because all of the library code
would be in namespaces, so you would need to prefix \ in front of
_every single_ function call in your library.

A change like this will also partially break code - rather than users
just appending 'namespace' at the beginning of every code file, they
would also need to update all global function calls. History has shown
us that breaking code (e.g. PHP4 - PHP5) slows adoption of new
versions.

Just my 2 cents.
Josh


On Mon, Oct 27, 2008 at 10:06 PM, Stan Vassilev | FM
<sv_forums@fmethod.com> wrote:
> Hi,
>
>
> Now that we have a separator, it's time to clarify what happened to the resolution order for functions and classes, which if I read Greg's messages, is still not clearly defined.
>
> 1) I think we've established that autoloading + fallback for classes is unworkable, as it either causes excessive autoload triggering, or alternatively allows internal classes to override unloaded but to-be-autoloaded namespaced classes. Then why is it still under consideration?
>
> 2) Making the backslash optional for internal functions means popular drop-in replacements for internal functions and extensions in global space, which work today, will break in a namespace, examples: libcurlemu. Also check any comments on PECL functions on php.net, and you'll see a myriad of drop-in replacements people use today.
>
> Also, for those who want to automatically convert their internal functions to backslash prefix for use in namespaces, you can use this quick snippet I wrote (works in 5.2.x too):
>
> http://pastebin.com/f13125acd
>
> I don't make guarantees it's perfect, but it can be improved and given to people as a porting aid.
>
> Opinions about how disruptive a mandatory backslash for global symbols *in namespaces* would be, are welcome. Keep in mind that making the backslash optional will lead to code breakage (such as for above drop-in replacements, class autoloading etc.) and slower performance (runtime resolution of function calls).
>
> Think of it as file paths. When you're inside a directory you need to prefix your path with "/" (eg "\") to refer to the root, but you don't need to do that when you're in the root directory.
>
> Regards,
> Stan Vassilev

---

## #41497 — Arvids Godjuks — 2008-10-28T07:12:51+00:00

URL: https://externals.io/message/41437#41497 · In reply to: #41496

I totally agree with Josh, same argument - resolving to global resources
should be by default, so we don't need to rewrite a lot of code, witch we
want to namespace. Namespaced functions will be called far less in code then
global ones.

2008/10/28 Josh <josh.sickmate@gmail.com>

> Hey,
>
> I think that using \ to prefix global symbols in namespaces would be
> quite dumb. It would feel counter-intuitive because then if your
> coding you would need to think to yourself, "am I in a namespace?",
> thus increasing the chance for simple errors. It would be incedibly
> annoying when writing php libraries, because all of the library code
> would be in namespaces, so you would need to prefix \ in front of
> _every single_ function call in your library.
>
> A change like this will also partially break code - rather than users
> just appending 'namespace' at the beginning of every code file, they
> would also need to update all global function calls. History has shown
> us that breaking code (e.g. PHP4 - PHP5) slows adoption of new
> versions.
>
> Just my 2 cents.
> Josh
>
>
> On Mon, Oct 27, 2008 at 10:06 PM, Stan Vassilev | FM
> <sv_forums@fmethod.com> wrote:
> > […]
> resolution order for functions and classes, which if I read Greg's messages,
> is still not clearly defined.
> > […]
> unworkable, as it either causes excessive autoload triggering, or
> alternatively allows internal classes to override unloaded but
> to-be-autoloaded namespaced classes. Then why is it still under
> consideration?
> > […]
> drop-in replacements for internal functions and extensions in global space,
> which work today, will break in a namespace, examples: libcurlemu. Also
> check any comments on PECL functions on php.net, and you'll see a myriad
> of drop-in replacements people use today.
> > […]
> functions to backslash prefix for use in namespaces, you can use this quick
> snippet I wrote (works in 5.2.x too):
> > […]
> people as a porting aid.
> > […]
> *in namespaces* would be, are welcome. Keep in mind that making the
> backslash optional will lead to code breakage (such as for above drop-in
> replacements, class autoloading etc.) and slower performance (runtime
> resolution of function calls).
> > […]
> prefix your path with "/" (eg "\") to refer to the root, but you don't need
> to do that when you're in the root directory.
> > […]

---

## #41499 — Stan Vassilev | FM — 2008-10-28T08:16:59+00:00

URL: https://externals.io/message/41437#41499 · In reply to: #41497

> History has shown
> us that breaking code (e.g. PHP4 - PHP5) slows adoption of new
> versions.

Bad example as PHP4 > 5 broke existing code. No existing code has namespaces 
in it. Anyway:

----------------

A yet another compromise is possible as the lesser evil:

Resolution for classes:

namespace Foo;
new Bar();

1) Try to find class Foo\Bar.
2) Try to autoload class Foo\Bar.
3) Try to fallback to global *internal or user* class Bar + E_NOTICE;

namespace Foo;
$result = bar();

1) Try to find function Foo\bar().
2) Try to fallback to global *internal or user* function bar().

They key change is: not to make difference between internal and user global 
functions, just fall back to global ones, so that there's no additional 
confusion among drop-in replacements, user resources, and internal 
resources.

Send feedback. Thanks.

Stan Vassilev

---

## #41501 — Karsten Dambekalns — 2008-10-28T10:32:16+00:00

URL: https://externals.io/message/41437#41501 · In reply to: #41499

Hi.

Stan Vassilev | FM wrote:
> A yet another compromise is possible as the lesser evil:
  ...
> They key change is: not to make difference between internal and user 
> global functions, just fall back to global ones, so that there's no 
> additional confusion among drop-in replacements, user resources, and 
> internal resources.
> 
> Send feedback. Thanks.

I like that way.

Regards,
Karsten

---

## #41502 — Josh — 2008-10-28T10:47:36+00:00

URL: https://externals.io/message/41437#41502 · In reply to: #41501

I like that way too


> Hi.
>
> Stan Vassilev | FM wrote:
> > […]
>
>  ...
> > […]
>
> I like that way.
>
> Regards,
> Karsten

---

## #41503 — Nathan Rixham — 2008-10-28T11:39:48+00:00

URL: https://externals.io/message/41437#41503 · In reply to: #41437

Stan Vassilev | FM wrote:
> Opinions about how disruptive a mandatory backslash for global symbols *in namespaces* would be, are welcome. Keep in mind that making the backslash optional will lead to code breakage (such as for above drop-in replacements, class autoloading etc.) and slower performance (runtime resolution of function calls).

personally not very disruptive, and after a few hours I think it would 
become second nature.

I'm sure there will be a few comments about this, but.. why not move all 
  internal functions and classes to a php namespace so that everything 
has to be in a namespace by default - ie no code that isn't in a namespace.

ie
php\file_get_contents(__FILE__);
instead of
\file_get_contents(__FILE__);

major major change but nice and strict

---

## #41506 — Josh — 2008-10-28T12:35:07+00:00

URL: https://externals.io/message/41437#41506 · In reply to: #41503

We are going to ignore the inherit problems that calling
file_get_contents(__FILE__); would cause...

Also, I disagree with a PHP namespace. the looseness of the language
is one of its strong points. Some things should be made strict, I
agree, bit it start with a php namespace and where does it end? If
your not careful you end up with c# or java where doing anything
requires going through hundreds of classes and packages.

Josh



> Stan Vassilev | FM wrote:
> > […]
>
> personally not very disruptive, and after a few hours I think it would
> become second nature.
>
> I'm sure there will be a few comments about this, but.. why not move all
>  internal functions and classes to a php namespace so that everything has to
> be in a namespace by default - ie no code that isn't in a namespace.
>
> ie
> php\file_get_contents(__FILE__);
> instead of
> \file_get_contents(__FILE__);
>
> major major change but nice and strict

---

## #41508 — Stan Vassilev | FM — 2008-10-28T12:46:32+00:00

URL: https://externals.io/message/41437#41508 · In reply to: #41506

> We are going to ignore the inherit problems that calling
> file_get_contents(__FILE__); would cause...
>
> Also, I disagree with a PHP namespace. the looseness of the language
> is one of its strong points. Some things should be made strict, I
> agree, bit it start with a php namespace and where does it end? If
> your not careful you end up with c# or java where doing anything
> requires going through hundreds of classes and packages.

Please let's avoid bad comparisons :P

We need to be very well aware that the concept of namespace in its simple, 
clear, understandable form, represents:

1) no globals, everything in the namespace is in the namespace, including 
vars, constants, functions, classes and nested namespaces.

2) to refer to a global namespace, there's no magical fallback to another 
namespace (the global one), you need to "use" it specify it in your call 
explicitly. The very idea of namespaces is, that other names don't leak into 
your namespace.

3) we'll likely see in a future edition of PHP (5.4? 5.5? 6.0?) that many 
currently global functions with "pseudo namespaces" like array_*(), 
string_*() etc will gain concurrent aliases in a namespace:  \array\*() 
\string\*()   since if we keep adding stuff in globals, then why introduce 
namespaces at all?

4) any fallback, fudge, name leak, partial implementation represents 
complication of the namespace concept, it's a compromise that makes 
namespaces harder to implement, understand and use, but easier in the short 
term for porting code and the "global functions all over the place" issue 
PHP is so often criticised for.

So, while I remain flexible on the scale of the options, I really wish 
people don't just think in the short term, since short term solutions are 
what caused the necessity to use "\" instead of "::" in the first place. 
When you're cornered by your ill past decisions, you either break BC (which 
we don't want to do), or add more WTF-s to the language as it evolves.

Regards, Stan Vassilev

---

## #41535 — Josh — 2008-10-28T19:27:24+00:00

URL: https://externals.io/message/41437#41535 · In reply to: #41508

Stan,

You are so correct. I change my vote. Im assuming putting everything
into the php namespace would allow 'use php', correct?
In this case all that would be needed to get existing functionality
would be to add 'use php' to the top of every file.

Perhaps a small piece of logic could be added where if there is no
namespace code in a file whatsoever (i.e. no 'namespace' or 'use'),
then php could implicitly call 'use php', so that tons of
non-namespace code would still work. Then when that code is converted
to namespaces, the users have the option to add 'use php' to every
file.

Also, sorry about the bad comparisons.

Regards,
Josh


On Tue, Oct 28, 2008 at 11:16 PM, Stan Vassilev | FM
<sv_forums@fmethod.com> wrote:
> > […]
>
> Please let's avoid bad comparisons :P
>
> We need to be very well aware that the concept of namespace in its simple,
> clear, understandable form, represents:
>
> 1) no globals, everything in the namespace is in the namespace, including
> vars, constants, functions, classes and nested namespaces.
>
> 2) to refer to a global namespace, there's no magical fallback to another
> namespace (the global one), you need to "use" it specify it in your call
> explicitly. The very idea of namespaces is, that other names don't leak into
> your namespace.
>
> 3) we'll likely see in a future edition of PHP (5.4? 5.5? 6.0?) that many
> currently global functions with "pseudo namespaces" like array_*(),
> string_*() etc will gain concurrent aliases in a namespace:  \array\*()
> \string\*()   since if we keep adding stuff in globals, then why introduce
> namespaces at all?
>
> 4) any fallback, fudge, name leak, partial implementation represents
> complication of the namespace concept, it's a compromise that makes
> namespaces harder to implement, understand and use, but easier in the short
> term for porting code and the "global functions all over the place" issue
> PHP is so often criticised for.
>
> So, while I remain flexible on the scale of the options, I really wish
> people don't just think in the short term, since short term solutions are
> what caused the necessity to use "\" instead of "::" in the first place.
> When you're cornered by your ill past decisions, you either break BC (which
> we don't want to do), or add more WTF-s to the language as it evolves.
>
> Regards, Stan Vassilev