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();
?
Just to make my post clear, I'm in favor of this approach for
non-qualified calls in a namespace.
- global
- autoload
- fail
Just to make my post clear, I'm in favor of this approach for non-
qualified calls in a namespace.
- global
- autoload
- fail
A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just
chatting on IRC and we all favor the following:
- ns 2) autoload (for classes) and global (for functions/constants)
- 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
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
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
- 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:
- Newcomers to PHP won't be writing namespaced code. So their WON'T be
confused. - They'll eventually use libraries with namespaces, in which case they're
STILL not affected. - 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. - 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
Lukas Kahwe Smith wrote:
Just to make my post clear, I'm in favor of this approach for
non-qualified calls in a namespace.
- global
- autoload
- fail
A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just
chatting on IRC and we all favor the following:
- ns 2) autoload (for classes) and global (for functions/constants) 3)
failSo 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
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
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