[RFC] Importing namespaced functions

12 years ago by Alexey Zakhlestin — view source — reply

unread

Hello internals,

I posted the initial idea for a use_function RFC a few months back. I would like to make the proposal official now, and open it for discussion.

I also did some work on a patch that probably still has some issues. Review on that is welcome as well.

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

I don't see much space for discussion :)
It's a very useful addition with nice explicit semantics and a small patch.

+1

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc

12 years ago by Martin Keckeis — view source — reply

unread

Hello internals,

I posted the initial idea for a use_function RFC a few months back. I
would like to make the proposal official now, and open it for discussion.

I also did some work on a patch that probably still has some issues.
Review on that is welcome as well.

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

Hello,

some questions:
Alias is not required, but is it possible?

Would it be possible to write something like this?
<?php
namespace MySpace;

use OtherLib\HtmlResponse;
use function html\div, html\p, html\em;

class MyClass{

public function getResponse(){
    return new HtmlResponse( div(p('Some', em('Text'))) );
}

}
?>

Best regards
Martin

12 years ago by Igor Wiedler — view source — reply

unread

Hi Martin,

Aliasing is possible, there is an example of it in the test cases of the patch 0.

As for your example, it's valid.

Regards,

Igor

Hello,

some questions:
Alias is not required, but is it possible?

Would it be possible to write something like this?
<?php
namespace MySpace;

use OtherLib\HtmlResponse;
use function html\div, html\p, html\em;

class MyClass{
public function getResponse(){
    return new HtmlResponse( div(p('Some', em('Text'))) );
}
}
?>

Best regards
Martin

12 years ago by Sebastian Krebs — view source — reply

unread

Hi,

Whats about constants?

Regards,
Sebastian
Am 19.07.2013 19:30 schrieb "Igor Wiedler" igor@wiedler.ch:

Hello internals,

I posted the initial idea for a use_function RFC a few months back. I
would like to make the proposal official now, and open it for discussion.

I also did some work on a patch that probably still has some issues.
Review on that is welcome as well.

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

Regards,

Igor

12 years ago by Igor Wiedler — view source — reply

unread

Hi Sebastian,

That's a very good point. I will start working on adding support for use const foo\BAR;. It makes sense to support both.

Should this be done as a variant? Or can I just include it in the RFC directly?

Cheers,

Igor

Hi,

Whats about constants?

Regards,
Sebastian

12 years ago by Igor Wiedler — view source — reply

unread

Hi,

Based on Sebastian's feedback I have updated the RFC and the patch to include a use const sequence that works just like use function, but for namespaced constants.

Example usage:

namespace foo\bar {
    const baz = 42;
}
 
namespace {
    use const foo\bar\baz;
    var_dump(baz);
}

I also fixed some other issues that the original patch had in the process (see commit history). Please keep the feedback coming.

Thanks,

Igor

12 years ago by Sebastian Krebs — view source — reply

unread

Hi,

Thanks for that.

But actually I don't see: Why is "use" not enough? As far as I can see your
example, why it would introduce a BC, doesn't really match to original
question, why "use function" is used. Especially I don't see any ambiguity:

foo(); // Always a function. You cannot call classes this way
new foo(); // always a class
foo::bar(); // Always a class

But the example I mentioned before

namespace {
function bar() {}}
namespace foo {
function bar() {}}
namespace {
use foo\bar;
bar();}

points to a different problem, which I didn't see solved by adding the
"function"-keyword to "use". Can you clarify this? Because I'd try to avoid
new syntax wherever possible.

Regards,
Sebastian

2013/7/23 Igor Wiedler igor@wiedler.ch

Hi,

Based on Sebastian's feedback I have updated the RFC and the patch to
include a use const sequence that works just like use function, but for
namespaced constants.

Example usage:
namespace foo\bar {
    const baz = 42;
}

namespace {
    use const foo\bar\baz;
    var_dump(baz);
}
I also fixed some other issues that the original patch had in the process
(see commit history). Please keep the feedback coming.

Thanks,

Igor

--
github.com/KingCrunch

12 years ago by Stas Malyshev — view source — reply

unread

Hi!

But actually I don't see: Why is "use" not enough? As far as I can see your
example, why it would introduce a BC, doesn't really match to original

Consider this:

use a\b\c as foo;

foo();

Now it would resolve to global function foo(). If use were changed to
apply to functions, it would resolve to function \a\b\c() instead.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Sebastian Krebs — view source — reply

unread

2013/7/23 Stas Malyshev smalyshev@sugarcrm.com

Hi!

But actually I don't see: Why is "use" not enough? As far as I can see
your
example, why it would introduce a BC, doesn't really match to original

Consider this:

use a\b\c as foo;

foo();

Now it would resolve to global function foo(). If use were changed to
apply to functions, it would resolve to function \a\b\c() instead.

But if I explicitly import "foo" this way, this is intended :?
Yes, "foo" could also be a classname, but right now it is also not part of
the language to detect collisions.
Additional I have never seen any core- or user-function, whose name could
be a classname to. Of course I've never seen every function ever written,
but even if this a real issue, how many people are really affected?

Regards,
Sebastian.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
github.com/KingCrunch

12 years ago by Stas Malyshev — view source — reply

unread

Hi!

But if I explicitly import "foo" this way, this is intended :?

No, it's a BC break and as such is not acceptable.

Additional I have never seen any core- or user-function, whose name
could be a classname to. Of course I've never seen every function ever
written, but even if this a real issue, how many people are really affected?

It is a BC break and as such it is a real issue.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Igor Wiedler — view source — reply

unread

Hi Sebastian,

The reason is precisely to avoid BC breaks, such as the one that you quoted from the FAQ.

Are you suggesting that such a BC break is acceptable for 5.6?

As much as I dislike introducing new syntax, keeping BC was the reason I did so.

12 years ago by Sebastian Krebs — view source — reply

unread

2013/7/23 Igor Wiedler igor@wiedler.ch

Hi Sebastian,

The reason is precisely to avoid BC breaks, such as the one that you
quoted from the FAQ.

Are you suggesting that such a BC break is acceptable for 5.6?

I don't fear BCs and actually I prefer BCs against weak compromises. This
depends on the weight of the BC ;)

But aside: I am a regular user, not a core-dev or something. I just comment.

As much as I dislike introducing new syntax, keeping BC was the reason I
did so.

--
github.com/KingCrunch

12 years ago by Yasuo Ohgaki — view source — reply

unread

Hi,

This patch good for extending PHP usability. IMHO.
Modern popular languages like Ruby and Javascript has way to extend/modify
existing object/method behaviors.
(Languages support like this: Smalltalk, JavaScript, Objective-C, Ruby,
Perl, Python, Groovy, and so on)

I just would like to point it out that there are many modern languages that
support similar feature. Therefore, I would like to see discussion rather
than whether this will or not will be part of PHP, but how this kind of
feature should be implemented.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

2013/7/20 Igor Wiedler igor@wiedler.ch

Hello internals,

I posted the initial idea for a use_function RFC a few months back. I
would like to make the proposal official now, and open it for discussion.

I also did some work on a patch that probably still has some issues.
Review on that is welcome as well.

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

Regards,

Igor

12 years ago by Stas Malyshev — view source — reply

unread

Hi!

This patch good for extending PHP usability. IMHO.
Modern popular languages like Ruby and Javascript has way to extend/modify
existing object/method behaviors.

PHP has it too, it is called runkit. However it makes reasoning about
the code much harder, so I do not think it is worth it to make it part
of standard PHP language. However, I do not see how this is related at
all to the RFC being discussed.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Stas,

2013/7/24 Stas Malyshev smalyshev@sugarcrm.com

This patch good for extending PHP usability. IMHO.
Modern popular languages like Ruby and Javascript has way to
extend/modify
existing object/method behaviors.

PHP has it too, it is called runkit. However it makes reasoning about
the code much harder, so I do not think it is worth it to make it part
of standard PHP language. However, I do not see how this is related at
all to the RFC being discussed.

RunKit is nice, but it's not a standard module and I suppose it will
not be standard.

This might be a poor example of usefulness of overriding existing
class/method, but proposed feature may be used for monkey patch
for instance.

http://en.wikipedia.org/wiki/Monkey_patch

There are issues as discussed in Wiki. So not having such
feature is valid option, but it's nice to have feature. Make strlen()
return number of chars instead of bytes, etc.

I don't have concrete idea right now. If there is cleaver way that
avoids disadvantages, I would like to see such feature by default
since almost all PHP competitors have this.

Any ideas that satisfy most of us?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Stas Malyshev — view source — reply

unread

Hi!

I don't have concrete idea right now. If there is cleaver way that
avoids disadvantages, I would like to see such feature by default
since almost all PHP competitors have this.

We are not in competition with other languages over number of features
implemented. "All cool boys do it" is not really a good answer, the good
answer should be why is it good for PHP as a language and as an
ecosystem having particular target audience and particular purpose. In
my opinion, changing what classes do in runtime fits the PHP's
traditional audience and purposes rather poorly. Of course, there are
always non-traditional ways of using it, it is a time-honored way of
hackers. For them, there's always runkit.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Igor Wiedler — view source — reply

unread

Hi Yasuo,

Monkey patching could be a very useful feature, especially for functions in a testing context.

But I agree with Stas that it's not really related to importing function/class symbols. Perhaps you should create a separate RFC for it.

RunKit is nice, but it's not a standard module and I suppose it will
not be standard.

This might be a poor example of usefulness of overriding existing
class/method, but proposed feature may be used for monkey patch
for instance.

http://en.wikipedia.org/wiki/Monkey_patch

There are issues as discussed in Wiki. So not having such
feature is valid option, but it's nice to have feature. Make strlen()
return number of chars instead of bytes, etc.

I don't have concrete idea right now. If there is cleaver way that
avoids disadvantages, I would like to see such feature by default
since almost all PHP competitors have this.

Any ideas that satisfy most of us?

12 years ago by Igor Wiedler — view source — reply

unread

Hi everyone,

I just wanted to bump this topic, since there's not been much feedback during the last few weeks. Comments on the patch are also welcome.

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

Thanks,

Igor

12 years ago by Robert Stoll — view source — reply

unread

Hi Igor,

Personally I like your RFC. I also like the fact that it is possible to
"replace" built-in functions where desired by declaring a corresponding use
statement.
I do not see aliases in your RFC but I guess it would also be possible to
write things like: use function foo\bar as foo;

cheers,
Robert

-----Ursprüngliche Nachricht-----
Von: Igor Wiedler [mailto:igor@wiedler.ch]
Gesendet: Donnerstag, 8. August 2013 14:29
An: internals@lists.php.net
Betreff: [PHP-DEV] Re: [RFC] Importing namespaced functions

Hi everyone,

I just wanted to bump this topic, since there's not been much feedback
during the last few weeks. Comments on the patch are also welcome.

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

Thanks,

Igor

--
To unsubscribe, visit:
http://www.php.net/unsub.php

12 years ago by Igor Wiedler — view source — reply

unread

Yes, aliases are supported just as you would expect. I will add an example to the RFC.

Thanks,

Igor

Hi Igor,

Personally I like your RFC. I also like the fact that it is possible to
"replace" built-in functions where desired by declaring a corresponding use
statement.
I do not see aliases in your RFC but I guess it would also be possible to
write things like: use function foo\bar as foo;

cheers,
Robert

12 years ago by Michael Wallner — view source — reply

unread

Hi everyone,

I just wanted to bump this topic, since there's not been much feedback during the last few weeks. Comments on the patch are also welcome.

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

I like it. It improves the state for non-OOP in PHP.

--
Regards,
Mike

12 years ago by Daniel Bingham — view source — reply

unread

Hey Igor,

I love the RFC, but how about:

use bar\baz() as baz;

As an alternative to "use function". Still new syntax, but a little less
wordy. I have nothing for "use const", but "use const" feels more natural
to me than "use function" does.

Just an idea for pondering!

Dan

Hi everyone,

I just wanted to bump this topic, since there's not been much feedback
during the last few weeks. Comments on the patch are also welcome.

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

I like it. It improves the state for non-OOP in PHP.

--
Regards,
Mike

12 years ago by Leigh — view source — reply

unread

On Aug 8, 2013 9:31 PM, "Daniel Bingham" daniel.bingham@ellislab.com
wrote:

Hey Igor,

I love the RFC, but how about:

use bar\baz() as baz;

As an alternative to "use function". Still new syntax, but a little less
wordy.

The parenthesis add the feeling that it should be evaluated imho, I.e. the
result of that function should be used as baz. That could possibly lead to
confusion. I know you're suggesting as an additional syntax not
alternative, but I don't get good vibes from it.

Also might not even be possible due to how the parser handles parenthesis,
but I'd have to look over the parser grammar to be sure.

But another +1 from me on the RFC as a whole. Now its there I can't believe
it took so long.

12 years ago by Daniel Bingham — view source — reply

unread

Hey Leigh,

I disagree that it suggests evaluation, but it could easily be a personal
interpretation thing. In my interpretation, when looking at use
statements, I know nothing is being evaluated. Symbols are being imported
into the namespace. How likely is it that baz returns something that can
be imported as a symbol? Would that even make sense as a feature,
importing the results of an evaluated function? Actually, given those two
questions, I can see how it would cause confusion if your initial
interpretation is that it is being evaluated.

For me, the parenthesis make it easier to read when scanning code. When
scanning use statements, I'm not scanning the keywords, I'm scanning the
included names. It's easier to look for parenthesis to denote functions,
it makes them stand out from the class names more. As in this example below:

use foo\bar\baz as baz;
use bar\foo\baz() as baz;
use bar\baz as bbaz;
use baz\foo\bar as bar;
use foo\bar() as bar;
use baz\bar as bbar;

Where as with "use function" I'd have to check back to the beginning of the
phrase to determine whether I was looking at a class name or function.

use foo\bar\baz as baz;
use function bar\foo\baz as baz;
use bar\baz as bbaz;
use baz\foo\bar as bar;
use function foo\bar as bar;
use baz\bar as bbar;

I think the difference mostly comes down to personal preference, and would
be somewhat alleviated by syntax highlighting.

Also, I have no knowledge of the PHP parser, so I have no idea how easy or
hard this would be to implement.

Daniel

On Aug 8, 2013 9:31 PM, "Daniel Bingham" daniel.bingham@ellislab.com
wrote:

Hey Igor,

I love the RFC, but how about:

use bar\baz() as baz;

As an alternative to "use function". Still new syntax, but a little less
wordy.

The parenthesis add the feeling that it should be evaluated imho, I.e. the
result of that function should be used as baz. That could possibly lead to
confusion. I know you're suggesting as an additional syntax not
alternative, but I don't get good vibes from it.

Also might not even be possible due to how the parser handles parenthesis,
but I'd have to look over the parser grammar to be sure.

But another +1 from me on the RFC as a whole. Now its there I can't
believe it took so long.

12 years ago by Igor Wiedler — view source — reply

unread

Hi Daniel,

Thanks for the suggestion. Since it is less straight-forward I would rather just move forward with the current syntax. I'd hate to see the proposal rejected because people did not like the syntax.

Regards,

Igor

Hey Igor,

I love the RFC, but how about:

use bar\baz() as baz;

As an alternative to "use function". Still new syntax, but a little less wordy. I have nothing for "use const", but "use const" feels more natural to me than "use function" does.

Just an idea for pondering!

Dan

Hi everyone,

I just wanted to bump this topic, since there's not been much feedback during the last few weeks. Comments on the patch are also welcome.

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

I like it. It improves the state for non-OOP in PHP.

--
Regards,
Mike

12 years ago by Marcello Duarte — view source — reply

unread

Hi,

Are there any thoughts regarding importing multiple functions of a namespace with a wildcard?

A use case being, for example, assertions from a testing framework.

use (or use function) TestingFramework\Assertions<chosen wildcard here>; // in java * is used for wildcard

Regards,
Marcello

Hi Daniel,

Thanks for the suggestion. Since it is less straight-forward I would rather just move forward with the current syntax. I'd hate to see the proposal rejected because people did not like the syntax.

Regards,

Igor

Hey Igor,

I love the RFC, but how about:

use bar\baz() as baz;

As an alternative to "use function". Still new syntax, but a little less wordy. I have nothing for "use const", but "use const" feels more natural to me than "use function" does.

Just an idea for pondering!

Dan

Hi everyone,

I just wanted to bump this topic, since there's not been much feedback during the last few weeks. Comments on the patch are also welcome.

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

I like it. It improves the state for non-OOP in PHP.

--
Regards,
Mike

12 years ago by Ferenc Kovacs — view source — reply

unread

On Thu, Aug 15, 2013 at 3:11 PM, Marcello Duarte
marcello.duarte@gmail.comwrote:

Hi,

Are there any thoughts regarding importing multiple functions of a
namespace with a wildcard?

A use case being, for example, assertions from a testing framework.

use (or use function) TestingFramework\Assertions<chosen wildcard here>;
// in java * is used for wildcard

currently this isn't supported for namespaced classes, so I think it would
be a good idea to keep this rfc consistent with what we have there.
of course a separate rfc can be created to introduce this feature, but from
the previous discussions I think that it would see a bit more debate, and
would also much harder to implement than what is proposed here.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

12 years ago by johannes@schlueters.de — view source — reply

unread

Hi,

Are there any thoughts regarding importing multiple functions of a
namespace with a wildcard?

A use case being, for example, assertions from a testing framework.

use (or use function) TestingFramework\Assertions<chosen wildcard
here>; // in java * is used for wildcard

Unlike Java and others we can't easily know all available choices.

Consider

use (or use function) Foo*;
use (or use function) Bar*;
foo();

Will this be a global foo, Foo\foo or Bar\bar? This becomes more funny
with the fact that PHP allows includes at runtime

use (or use function) Foo*;
use (or use function) Bar*;
foo(); // only \foo() exists
include 'Foo\foo.php';
foo(); // Foo\foo() now exists, too

johannes

12 years ago by Igor Wiedler — view source — reply

unread

I was about to make the same point as Johannes. Trying all possible variants in the autoloader is simply too slow (and in fact the main reason why we don't have function autoloading). On the flip-side, the current proposal would allow adding function autoloading more easily in the future.

Another note: To address the issue in a different way, some sort of syntax for importing multiple names would be nice. Something like:

from foo use bar, baz;

But that is way out of scope, and should be done as a separate proposal.

Regards,

Igor

Hi,

Are there any thoughts regarding importing multiple functions of a
namespace with a wildcard?

A use case being, for example, assertions from a testing framework.

use (or use function) TestingFramework\Assertions<chosen wildcard
here>; // in java * is used for wildcard

Unlike Java and others we can't easily know all available choices.

Consider

use (or use function) Foo*;
use (or use function) Bar*;
foo();

Will this be a global foo, Foo\foo or Bar\bar? This becomes more funny
with the fact that PHP allows includes at runtime

use (or use function) Foo*;
use (or use function) Bar*;
foo(); // only \foo() exists
include 'Foo\foo.php';
foo(); // Foo\foo() now exists, too

johannes

12 years ago by Stas Malyshev — view source — reply

unread

Hi!

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

Looking at the patch:

use function bar as bar;
does not produce any warning

use function x\foo as bar;

function bar() {
echo "OK!";
}

Does not produce any warnings or errors, though it should be.

This code:
namespace x;
use foo as bar;
use function foo as bar;
bar();

Produces a crash.

I would suggest this patch needs a bit more work on corner cases.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Igor Wiedler — view source — reply

unread

Hi Stas,

Thanks for the notes. I will address these issues, hopefully during the next few days.

Good job spotting them!

Regards,

Igor

Hi!

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

Looking at the patch:

use function bar as bar;
does not produce any warning

use function x\foo as bar;

function bar() {
echo "OK!";
}

Does not produce any warnings or errors, though it should be.

This code:
namespace x;
use foo as bar;
use function foo as bar;
bar();

Produces a crash.

I would suggest this patch needs a bit more work on corner cases.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Michael Wallner — view source — reply

unread

Hi Stas,

Thanks for the notes. I will address these issues, hopefully during the next few days.

Nay news on that?

--
Regards,
Mike

12 years ago by Igor Wiedler — view source — reply

unread

Hi,

The crash has been fixed, I'm still working on defining a function that has the same name as an alias in the current namespace.

Regards,

Igor

Hi Stas,

Thanks for the notes. I will address these issues, hopefully during the next few days.

Nay news on that?

--
Regards,
Mike

12 years ago by Igor Wiedler — view source — reply

unread

Hi,

I just looked into the first issue you mentioned. The following does not produce a warning either currently:

use bar as bar;

As such, I would say that it would be inconsistent to produce a warning for functions. Do you agree?

Regards,

Igor

Hi!

RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388

Looking at the patch:

use function bar as bar;
does not produce any warning

12 years ago by Stas Malyshev — view source — reply

unread

Hi!

use bar as bar;

Hmm... they probably should both produce a notice. But if it's hard to
do, then ok to do the same thing as class does.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

[RFC] Importing namespaced functions

Now it would resolve to global function foo(). If use were changed to apply to functions, it would resolve to function \a\b\c() instead.

PHP has it too, it is called runkit. However it makes reasoning about the code much harder, so I do not think it is worth it to make it part of standard PHP language. However, I do not see how this is related at all to the RFC being discussed.

Now it would resolve to global function foo(). If use were changed to
apply to functions, it would resolve to function \a\b\c() instead.

PHP has it too, it is called runkit. However it makes reasoning about
the code much harder, so I do not think it is worth it to make it part
of standard PHP language. However, I do not see how this is related at
all to the RFC being discussed.