# [RFC lite] implement import of functions in namespace

- Thread: https://externals.io/message/42755
- Original archive: https://news-web.php.net/php.internals/42755
- Started by Greg Beaver on 2009-01-21T20:19:53+00:00
- Messages: 10
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #42755 — Greg Beaver — 2009-01-21T20:19:53+00:00

URL: https://externals.io/message/42755#42755

This is a "testing of the waters" RFC.  If there is interest, it will be
followed with a patch.  It should be noted that the patch for this has
been available through the various vortexes of namespace syntax for over
a year now, and it is an extremely simple patch.

[RFC]
Implement importing of functions to complement importing of classes and
namespaces.

example:

<?php
namespace foo;
include 'blah.php'; // defines function bar in namespace oof

use function oof\bar;
use function \strlen;

bar(); // calls oof\bar()
$a = strlen('hi'); // calls global function strlen
?>

[Problems this solves/Use cases]
(1) Readability:
* can make code more readable, much like importing classes/namespaces,
by shortening line lengths and simplifying complex compound expressions

(2) Backwards/Forwards compatibility
* Occasionally, an internal function is extended with additional
parameters.  With function import, this can be accomplished in old versions.

Example (pretend parameter "encoding" is added to `strlen()` in PHP 6.0):

<?php
namespace Util {
function strlen($string, $encoding = 'ISO-8559-1')
{
    $a = `phpversion()`;
    if ($a[0] >= 6) {
        return \strlen($string, $encoding); // use internal implementation
    }
    // now for the simulated parameter
    switch ($encoding) {
        ...
    }
}
}

use function Util\strlen;
// now code following will work in all PHP versions, and is
forward-compatible to PHP 6
?>

[Proposed syntax changes]

Function import is accomplished with the keyword "function" (T_FUNCTION
token) as in

 `T_USE` T_FUNCTION [use_statement]

use_statement can be any of \func or nsname\func or \nsname\func

Samples:

<?php
use function \globalfunc;
use function nsname\func;
use function \nsname\func;
?>

Just like the regular implementation of use for classes/namespaces:

<?php
use function globalfunc;
?>

will raise a warning that this has no effect (import in global scope of
unqualified name is meaningless).

<?php
namespace inside\namespace;
use function globalfunc;
?>

will act like:

<?php
namespace inside\namespace;
use function \globalfunc;
?>

[Drawbacks]
1) requires changing the engine near beta
2) adds new syntax to namespaces

[Non-issues/Slight issues]
1) would introduce one hash lookup on unqualified function calls at
compile-time if any "use" statement exists in the script, which is
unlikely to be detectable as a performance difference for even the
largest scripts.

Thanks,
Greg

---

## #42763 — Steph Fox — 2009-01-22T01:41:12+00:00

URL: https://externals.io/message/42755#42763 · In reply to: #42755

Having ascertained that Lukas did not shoot himself on seeing this...

> This is a "testing of the waters" RFC.  If there is interest, it will be
> followed with a patch.  It should be noted that the patch for this has
> been available through the various vortexes of namespace syntax for over
> a year now, and it is an extremely simple patch.
> 
> [RFC]
> Implement importing of functions to complement importing of classes and
> namespaces.

Sounds like a darn good idea to me.

- Steph

---

## #42764 — Larry Garfield — 2009-01-22T06:03:26+00:00

URL: https://externals.io/message/42755#42764 · In reply to: #42755

On Wednesday 21 January 2009 2:19:53 pm Greg Beaver wrote:

> [Drawbacks]
> 1) requires changing the engine near beta

Legitimate concern, but I happily defer t the maintainers here.

> 2) adds new syntax to namespaces

If I'm reading the RFC properly, it extends the existing syntax in a logical 
way without introducing any new reserved words.  My only question then would 
be should we change the way classes are imported to use the keyword "class", 
to parallel this syntax?  Eg:

use class Foo\Bar;
use function Foo\fanciness;

If we're concerned about breaking code written for the existing alphas, 
perhaps "class" could be implied if not specified, so that we can recommend 
using it but not break existing code?  I'm not sure if there's a performance 
concern there.

> [Non-issues/Slight issues]
> 1) would introduce one hash lookup on unqualified function calls at
> compile-time if any "use" statement exists in the script, which is
> unlikely to be detectable as a performance difference for even the
> largest scripts.
>
> Thanks,
> Greg

+1 from me.

-- 
Larry Garfield
larry@garfieldtech.com

---

## #42771 — Richard Quadling — 2009-01-22T11:00:52+00:00

URL: https://externals.io/message/42755#42771 · In reply to: #42764

2009/1/22 Larry Garfield <larry@garfieldtech.com>:
> On Wednesday 21 January 2009 2:19:53 pm Greg Beaver wrote:
> > […]
>
> If I'm reading the RFC properly, it extends the existing syntax in a logical
> way without introducing any new reserved words.  My only question then would
> be should we change the way classes are imported to use the keyword "class",
> to parallel this syntax?  Eg:
>
> use class Foo\Bar;
> use function Foo\fanciness;
>
> If we're concerned about breaking code written for the existing alphas,
> perhaps "class" could be implied if not specified, so that we can recommend
> using it but not break existing code?  I'm not sure if there's a performance
> concern there.
> --
> Larry Garfield
> larry@garfieldtech.com

I like conformity. If my voice counts, I would be happy to accept this
as a BC. If necessary, all for "class" to be implied until V6 or V5.4
and mark it as an `E_STRICT` or `E_DEPRECATED` ("use Foo\Bar" to include a
class is deprecated, use "use class Foo\Bar" instead) sort of thing.
This allows current code to run. Tells the alpha testers there code is
in need of an upgrade, and gives them time to do so.

Richard.

-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

---

## #42773 — johannes@php.net — 2009-01-22T12:19:49+00:00

URL: https://externals.io/message/42755#42773 · In reply to: #42755

> [RFC]
> Implement importing of functions to complement importing of classes and
> namespaces.

It was aid that import should only work with classes. We might extend
that but not for 5.3! The only engine feature to change are closures and
there we either get a compromise about the prototyping/OO stuff or
commit my patch to remove them for the time being.
http://schlueters.de/~johannes/php/5.3-remove-closure.diff.txt
(patch is missing the reflection part)

It's been a long time for 5.3 already ... let's try to make release
cycles shorter, not longer!

johannes

---

## #42774 — Pierre Joye — 2009-01-22T12:38:31+00:00

URL: https://externals.io/message/42755#42774 · In reply to: #42773

> 
> > […]
>
> It was aid that import should only work with classes. We might extend
> that but not for 5.3! The only engine feature to change are closures and
> there we either get a compromise about the prototyping/OO stuff or
> commit my patch to remove them for the time being.
> http://schlueters.de/~johannes/php/5.3-remove-closure.diff.txt
> (patch is missing the reflection part)
>
> It's been a long time for 5.3 already ... let's try to make release
> cycles shorter, not longer!

There is no pressure on us to push a release. If some features are
missing to make the new additions complete then let us complete them
before 5.3.0-final. That's exactly why we have test releases or tests
phases. It is really annoying to have half backed features
(caricature) when a final release is fired, and then have to wait .1,
.2 or .3 to finally get the full working implementation. It is not
possible to be 100% sure, but for these two cases (closure and this
one), problems have been identified clearly, let the respective
developers fix them.

About removing the closure or anything else only because we want the
beta1 out this month is a bad choice and I strongly disagree with this
decision (if it happens).

Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

---

## #42777 — Guilherme Blanco — 2009-01-22T13:22:42+00:00

URL: https://externals.io/message/42755#42777 · In reply to: #42774

Removing an already working feature is just weird IMHO.

Also... this proposal reminds me to an older discussion (please for
God sake, no flaming mails!) that Greg did some time ago that if using
"use class Foo\Bar;" was enough to differ between a static call and a
ns call. It as one of the proposals to solve the :: issue.

IMHO I'm more than happy with something like:

use Foo\Bar as Baz;
$var = Baz\myFunc();

There's no need to introduce more weirdness things no 5.3.... let's
just try to get it out of the box and fix the possible introduced
issues.
We're already in alpha3 and I think when switching from alpha to beta
is something like a feature freeze.


Regards,


> 
> > […]
>
> There is no pressure on us to push a release. If some features are
> missing to make the new additions complete then let us complete them
> before 5.3.0-final. That's exactly why we have test releases or tests
> phases. It is really annoying to have half backed features
> (caricature) when a final release is fired, and then have to wait .1,
> .2 or .3 to finally get the full working implementation. It is not
> possible to be 100% sure, but for these two cases (closure and this
> one), problems have been identified clearly, let the respective
> developers fix them.
>
> About removing the closure or anything else only because we want the
> beta1 out this month is a bad choice and I strongly disagree with this
> decision (if it happens).
>
> Cheers,
> --
> Pierre
>
> http://blog.thepimp.net | http://www.libgd.org
>
> --
> 
> 
>
>



-- 
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Paulo - SP/Brazil

---

## #42783 — Stanislav Malyshev — 2009-01-22T15:56:52+00:00

URL: https://externals.io/message/42755#42783 · In reply to: #42771

Hi!

> I like conformity. If my voice counts, I would be happy to accept this
> as a BC. If necessary, all for "class" to be implied until V6 or V5.4

But "use" doesn't import classes, it imports names. The name doesn't 
have to be class at all.

> and mark it as an `E_STRICT` or `E_DEPRECATED` ("use Foo\Bar" to include a
> class is deprecated, use "use class Foo\Bar" instead) sort of thing.
> This allows current code to run. Tells the alpha testers there code is
> in need of an upgrade, and gives them time to do so.

-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #42784 — Stanislav Malyshev — 2009-01-22T15:59:46+00:00

URL: https://externals.io/message/42755#42784 · In reply to: #42774

Hi!

> There is no pressure on us to push a release. If some features are
> missing to make the new additions complete then let us complete them
> before 5.3.0-final. That's exactly why we have test releases or tests
> phases. It is really annoying to have half backed features

Yes there is pressure. We didn't have release for very long time, and 
each time we try there's some additional new "small feature" that 
somebody wants to squeeze in. We have to stop somewhere.
And namespaces aren't nearly "half-baked". They are fully baked and it's 
time to release them.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #42786 — johannes@php.net — 2009-01-22T17:56:25+00:00

URL: https://externals.io/message/42755#42786 · In reply to: #42774

> > […]
> 
> There is no pressure on us to push a release.

Yes, if we decide to never release it's fine, but if we want to release
ever we have to draw the line at some moment. In June or July traits
were rejected since we want to release "soon" since then we go from
minor delay to minor delay and Lukas and I think it's a good time to
finally draw the line.

> About removing the closure or anything else only because we want the
> beta1 out this month is a bad choice and I strongly disagree with this
> decision (if it happens).

If we can agree on Christian's last proposal that's better if not I'd
say (Lukas agrees) we make sure we have something releasable on which we
can build "full closure OO support" lateron without breaking anything.
(either making sure the closure implementation is in a state that we can
add that stuff lateron without harm or, if nothing else helps, as last
step, dropping them)

>From time to time we have to make releases and focus on them.

johannes