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.
-
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?
-
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):
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
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.
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?
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):
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
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.
JoshOn 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.
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?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):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
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();
- Try to find class Foo\Bar.
- Try to autoload class Foo\Bar.
- Try to fallback to global internal or user class Bar + E_NOTICE;
namespace Foo;
$result = bar();
- Try to find function Foo\bar().
- 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
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
I like that way too
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
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
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:
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
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:
-
no globals, everything in the namespace is in the namespace, including
vars, constants, functions, classes and nested namespaces. -
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. -
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? -
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
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:
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:
no globals, everything in the namespace is in the namespace, including
vars, constants, functions, classes and nested namespaces.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.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?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