Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] Clarifying the resolution rules

Posted by Stan Vassilev | FM 
Stan Vassilev | FM
[PHP-DEV] Clarifying the resolution rules
October 27, 2008 12:40PM
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
Josh
Re: [PHP-DEV] Clarifying the resolution rules
October 28, 2008 04:00AM
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
<[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Arvids Godjuks
Re: [PHP-DEV] Clarifying the resolution rules
October 28, 2008 08:15AM
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 <[email protected]>

> 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
> <[email protected]> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Stan Vassilev | FM
Re: [PHP-DEV] Clarifying the resolution rules
October 28, 2008 09:20AM
> 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Karsten Dambekalns
Re: [PHP-DEV] Clarifying the resolution rules
October 28, 2008 11:35AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Josh
Re: [PHP-DEV] Clarifying the resolution rules
October 28, 2008 11:50AM
I like that way too

On Tue, Oct 28, 2008 at 9:02 PM, Karsten Dambekalns <[email protected]> wrote:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nathan Rixham
[PHP-DEV] Re: Clarifying the resolution rules
October 28, 2008 12:45PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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


On Tue, Oct 28, 2008 at 10:09 PM, Nathan Rixham <[email protected]> wrote:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stan Vassilev | FM
Re: [PHP-DEV] Re: Clarifying the resolution rules
October 28, 2008 01:50PM
> 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
<[email protected]> 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:
>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login