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]
- requires changing the engine near beta
- adds new syntax to namespaces
[Non-issues/Slight issues]
- 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
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
On Wednesday 21 January 2009 2:19:53 pm Greg Beaver wrote:
[Drawbacks]
- requires changing the engine near beta
Legitimate concern, but I happily defer t the maintainers here.
- 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]
- 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
2009/1/22 Larry Garfield larry@garfieldtech.com:
On Wednesday 21 January 2009 2:19:53 pm Greg Beaver wrote:
- 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.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!"
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_STRICTorE_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
[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
[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!
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
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,
[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!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
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
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.
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