[RFC] Importing namespaced functions

Alexey Zakhlestin

13 years ago

On 19.07.2013, at 21:29, Igor Wiedler <igor@wiedler.ch> wrote:

> 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

Martin Keckeis

13 years ago

On 19.07.2013, at 21:29, Igor Wiedler <igor@wiedler.ch> wrote:

>
> > 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

Igor Wiedler

13 years ago

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

[0]: https://github.com/igorw/php-src/blob/use-function/Zend/tests/use_function/alias.phpt

On Jul 23, 2013, at 10:10 AM, Martin Keckeis <martin.keckeis1@gmail.com> wrote:

Sebastian Krebs

13 years ago

Hi,

Whats about constants?

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

Igor Wiedler

13 years ago

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

On Jul 23, 2013, at 4:23 PM, Sebastian Krebs <krebs.seb@gmail.com> wrote:

Igor Wiedler

13 years ago

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

Sebastian Krebs

13 years ago

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

Stas Malyshev

13 years ago

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

Sebastian Krebs

13 years ago

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

Stas Malyshev

13 years ago

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

Igor Wiedler

13 years ago

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.

Sebastian Krebs

13 years ago

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

Yasuo Ohgaki

13 years ago

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>

Stas Malyshev

13 years ago

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

Yasuo Ohgaki

13 years ago

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

Stas Malyshev

13 years ago

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

Igor Wiedler

13 years ago

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.

On Jul 24, 2013, at 7:28 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

Igor Wiedler

13 years ago

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

Robert Stoll

13 years ago

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

--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
http://www.php.net/unsub.php

Igor Wiedler

13 years ago

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

Thanks,

Igor

On Aug 8, 2013, at 8:17 PM, "Robert Stoll" <rstoll@tutteli.ch> wrote:

Michael Wallner

13 years ago

On 8 August 2013 14:29, Igor Wiedler <igor@wiedler.ch> wrote:

> 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

Daniel Bingham

13 years ago

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

On Thu, Aug 8, 2013 at 2:44 PM, Michael Wallner <mike@php.net> wrote:

Leigh

13 years ago

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.

Daniel Bingham

13 years ago

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 Fri, Aug 9, 2013 at 1:16 PM, Leigh <leight@gmail.com> wrote:

Igor Wiedler

13 years ago

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

On Aug 8, 2013, at 10:30 PM, Daniel Bingham <daniel.bingham@ellislab.com> wrote:

Marcello Duarte

13 years ago

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

On 15 Aug 2013, at 14:06, Igor Wiedler wrote:

Ferenc Kovacs

13 years ago

On Thu, Aug 15, 2013 at 3:11 PM, Marcello Duarte
<marcello.duarte@gmail.com>wrote:

> 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

Johannes Schlueter

13 years ago

On Thu, 2013-08-15 at 14:11 +0100, Marcello Duarte wrote:

> 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

Igor Wiedler

13 years ago

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

On Aug 15, 2013, at 3:24 PM, Johannes Schlüter <johannes@schlueters.de> wrote:

Stas Malyshev

13 years ago

Hi!

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

Looking at the patch:

1. use function bar as bar;
does not produce any warning

2.
use function x\foo as bar;

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

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

3. 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

Igor Wiedler

13 years ago

Hi Stas,

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

Good job spotting them!

Regards,

Igor

On Aug 19, 2013, at 3:32 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

Michael Wallner

13 years ago

On 20 August 2013 23:29, Igor Wiedler <igor@wiedler.ch> wrote:

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

Nay news on that?

--
Regards,
Mike

Igor Wiedler

13 years ago

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

On Aug 21, 2013, at 10:06 AM, Michael Wallner <mike@php.net> wrote:

Igor Wiedler

13 years ago

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

On Aug 19, 2013, at 3:32 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

Stas Malyshev

13 years ago

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