# Namespace Resolution

- Thread: https://externals.io/message/41653
- Original archive: https://news-web.php.net/php.internals/41653
- Started by Ryan Panning on 2008-11-04T17:37:12+00:00
- Messages: 9
- 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

---

## #41653 — Ryan Panning — 2008-11-04T17:37:12+00:00

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

First, I want to say thanks for determining the best separator. Even 
though it's not what everyone would like, it's what would work best.

Second, sorry for starting a new thread. To me, continuing the 
resolution discussion in the "namespace separator and whining" isn't the 
correct place.

Third, moderating this list may help the developers keep the noise down 
but user-land people, like myself, need to have some input too. Not sure 
if this was proposed yet but what about a "trial period" where if a 
person shows that they don't "over-post" they get un-moderated.

Finally, down to business. What I would like to see is that any call not 
prefixed with a direct namespace or not "used" at the top, be considered 
a global request. This forces users to either define what they are going 
to "use" or directly define what namespace is requested. Ex:

<?php
namespace NsA\NsB;

class ClassB {
     public function methodB() {
         namespace\func_b();
     }
}

function func_b() {
     print 'I am in NsB';
}
?>

<?php
namespace NsA\NsB\NsC;

function func_c() {
     print 'I am in NsC';
}
?>

<?php
include 'NsB.php';
include 'NsC.php';

use 'NsA\NsB\NsC\func_c()';

$obj = new NsA\NsB\ClassB;
$obj->methodB();
func_c();
?

---

## #41654 — Ryan Panning — 2008-11-04T17:43:02+00:00

URL: https://externals.io/message/41653#41654 · In reply to: #41653

Just to make my post clear, I'm in favor of this approach for 
non-qualified calls in a namespace.

1. global
2. autoload
3. fail

---

## #41659 — Andrey Hristov — 2008-11-04T18:05:48+00:00

URL: https://externals.io/message/41653#41659 · In reply to: #41653

Ryan Panning wrote:

> use 'NsA\NsB\NsC\func_c()';

OMG!!!! That looks UGLY!!!!11111

> $obj = new NsA\NsB\ClassB;
> $obj->methodB();
> func_c();
> ?>
> 

Best,
Andrey

---

## #41662 — David Coallier — 2008-11-04T21:20:30+00:00

URL: https://externals.io/message/41653#41662 · In reply to: #41659

2008/11/4 Andrey Hristov <php@hristov.com>

> Ryan Panning wrote:
>
>  use 'NsA\NsB\NsC\func_c()';
> > […]
>
> OMG!!!! That looks UGLY!!!!11111
>

This is exactly the kind of comment that is both useless and pointless.
Could you please make sure that you have a valid point with a subject,
arguments, examples or at least ideas and a direction next time you post.

Thanks,


-- 
Slan,
David

---

## #41696 — Lukas Kahwe Smith — 2008-11-05T21:32:52+00:00

URL: https://externals.io/message/41653#41696 · In reply to: #41654

> Just to make my post clear, I'm in favor of this approach for non- 
> qualified calls in a namespace.
>
> 1. global
> 2. autoload
> 3. fail


A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just  
chatting on IRC and we all favor the following:

1) ns 2) autoload (for classes) and global (for functions/constants)  
3) fail

So no fallback to the global namespace for classes, but fallback for  
all functions/constants (regardless of internal or not)

Here are some reasons why we do not want a fallback for classes:
- there are far less (and will likely be) global classes compared to  
functions, also class names need to be typed less often than functions  
to begin with => its less of an issue for classes
- more importantly Stas pointed out that "if we don't do it without  
fallback, THEN we'd have problems with typehints, since then we would  
have to start autoloading stuff i.e. fallback would force autoloading  
in some cases where presently there's none (instanceof, typehint, etc.)"

Here are some reasons why we felt that functions/constants should  
fallback:
- most namespace users will be using classes and not functions
- people expect direct access to the vast number of php functions/ 
constants

Here is the reason why we felt we should not limit this to internal  
functions only:
- <@Derick> some people provide drop in libraries for extensions such  
as curl
- at the same time some people might choose to implement frequently  
used global functions inside an extension, which would result in a  
change of behavior (though this is not such a big deal)

Here is a reason why we would limit this to international functions  
only:
- <@Stas> but note that global user-space fallback for function means  
run-time resolution (which may be ok, but slower - no caching  
resolution in bytecode cache)

However given that we expect the fallback to mainly be used for  
situations where one wants to provide a user land fallback  
implementation of something that would usually be available as an  
extension, it seems obvious that this is not the ideal case for  
performance to begin with, and the sole reason is to be able to run  
even in the absence of the ideal situation for performance where the  
function would be provided via an extension.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #41698 — Stan Vassilev | FM — 2008-11-05T22:29:15+00:00

URL: https://externals.io/message/41653#41698 · In reply to: #41696

>Here is a reason why we would limit this to international functions  only:
>- <@Stas> but note that global user-space fallback for function means 
>run-time resolution (which may be ok, but slower - no caching  resolution 
>in bytecode cache)


Hi,

Not true: you can't resolve it at compile time with internal-only functions, 
since you still don't know what *namespaced user functions* will be loaded 
at runtime with overlapping names.

I.e. :

----FILE aaa.php----

namespace Foo;
function `strpos()` {}

----FILE bbb.php----

namespace Foo;
if (runtime condition) include 'aaa.php';
 `strpos()`; // parse-time resolution will ignore the loaded Foo\strpos() and 
resolve to internal anyway.

So, no performance benefit whatsoever, any fallback requires *runtime* 
resolution.

Furthermore, don't you guys see that coding IDE-s will have issues with code 
hinting those functions. Is it the namespaced function or the global one? 
The IDE can't know, an IDE can't resolve vague runtime conditional includes.

Eclipse PDT works great right now, with autoload and all, since it a given 
functionc/class identifier can be either internal, or in the project, and 
each has a unique name. With the magical fallbacks, all this goes to hell.

Regards,
Stan Vassilev

---

## #41700 — Stan Vassilev | FM — 2008-11-05T22:46:40+00:00

URL: https://externals.io/message/41653#41700 · In reply to: #41696

> Here are some reasons why we felt that functions/constants should 
> fallback:
> - most namespace users will be using classes and not functions

This is a self-fulfilling prophecy, the more you open a gap between classes 
and functions, the more people will stick with the richer functionality 
since it's just too much hassle to bother with two different paradigms.

Case in point: do you know a major reason why people keep using static 
methods to "fake" functions? It's not as much to namespace it. I mean 
Foo::bar() or Foo_bar(), who cares? It's all the same.

But the big difference is, I don't have to explicitly load the function 
library if it's a static class. Classes have autoload, functions 
mysteriously don't. Hence, even I have abandoned using functions today and 
use fugly static method hacks. It's less hassle to do it wrong right now, 
than do it right. So I do it wrong.

Namespaces won't change any of this, since I still can't autoload my 
function library.

Regards,
Stan Vassilev

---

## #41701 — Stan Vassilev | FM — 2008-11-05T22:50:12+00:00

URL: https://externals.io/message/41653#41701 · In reply to: #41696

> - people expect direct access to the vast number of php functions/ 
> constants

Do you know rule 1 in #phpc? This is one of those cases.

People want :: and not backslash.
People want global stuff to resolve in their namespace (how does this make 
any sense? the very idea of a namespace is to avoid this stuff).

We should know better, and in fact we do know better since all those 
resolution order discussions won't be happening, trying to find a perfect 
intersection between what we know works, and what the (less informed) 
general public thinks it wants.

And the reality is that the whole hatred to the mandatory leading slash is 
overblown beyond any proportions:

1) Newcomers to PHP won't be writing namespaced code. So their WON'T be 
confused.
2) They'll eventually use libraries with namespaces, in which case they're 
STILL not affected.
3) They'll be pasting code samples from the manual and forums in a blank 
file in global space, so they STILL won't be affected.
4) One day, their projects will start growing a lot, their experience with 
it, and they'll have the basic clue to prefix their global classes/functions 
when inside a namespace. So they STILL won't be affected.

What do we do instead? We discuss how to optimize the non-existing scenario 
of noobs being irritated or confused when hammering global identifiers in a 
namespace, while producing unimanginable pain to every PHP coder out there 
from all ranges of experience and knowledge, with magical fallbacks and 
autoload mysteries.

I suggest we all clear our minds a little and give a serious thought to all 
this again. If you just say "no fallbacks", some people will bitch 2-3 days, 
then try it, and see that it was not all that bad after all.

Regards,
Stan Vassilev

---

## #41702 — Gregory Beaver — 2008-11-05T23:34:06+00:00

URL: https://externals.io/message/41653#41702 · In reply to: #41696

Lukas Kahwe Smith wrote:
> 
> 
> 
> > […]
> 
> 
> A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just
> chatting on IRC and we all favor the following:
> 
> 1) ns 2) autoload (for classes) and global (for functions/constants) 3)
> fail
> 
> So no fallback to the global namespace for classes, but fallback for all
> functions/constants (regardless of internal or not)

Independently, I made this patch yesterday to do what you're describing.

http://pear.php.net/~greg/resolv.patch.txt

It turns out that we already fallback to all global constants (not just
internal ones).  Only functions and classes were falling back to
internal-only.

Once someone reviews and commits we can focus solely on bugfixes for
namespaces and finally get out alpha3 within a week (my guesstimate,
based on what things look like).

Regarding the patch: it is minimal changes for class name resolution.
It only removes the lines that tell the engine to do fallback for
classes.  We may also want to remove the few lines of functionality that
does fallback to internal for classes in zend_fetch_class, but I'd
rather wait on that, and do a full review of the way those constants are
being used in ZEND_FETCH_CONSTANT and all the other 5 places constants
are resolved, as I recycled some constants, which could use some
renaming.  The patch also does not update any tests, some of which
should fail.

Thanks,
Greg