On Sep 18, 2013, at 11:53 AM, Leigh lei...@gmail.com wrote:
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
...
Thoughts?
For isset() there is a good reason to do this, because the var might not
Hi Bob,
Thanks for working on this.
The amount of reserved keywords in PHP is quite large and I've experienced many
cases where it would have been useful to use them. Especially when implementing
a DSL, parser, code generator (quite common use case with template engines, and
various other
if that
is not acceptable, in which case it can be extended.
Regards,
Igor
On Aug 15, 2013, at 4:08 PM, Igor Wiedler i...@wiedler.ch wrote:
Hello internals,
About 3 weeks have passed since I announced the use_function RFC. A number of
issues were raised, and I believe all of them have been
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 m...@php.net wrote:
On 20 August 2013 23:29, Igor Wiedler i...@wiedler.ch wrote:
Hi Stas
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
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 smalys...@sugarcrm.com wrote:
Hi!
RFC: https://wiki.php.net/rfc/use_function
Patch:
On Thu, Aug 8, 2013 at 2:44 PM, Michael Wallner m...@php.net wrote:
On 8 August 2013 14:29, Igor Wiedler i...@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
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.
Hello internals,
About 3 weeks have passed since I announced the use_function RFC. A number of
issues were raised, and I believe all of them have been resolved at this point.
I would like to initiate the voting phase.
RFC: https://wiki.php.net/rfc/use_function
Patch:
Hi Peter,
This *is* the [VOTE] thread. Am I missing something? :)
Regards,
Igor
On Aug 15, 2013, at 4:20 PM, Peter Cowburn petercowb...@gmail.com wrote:
Don't forget to create a new [VOTE] thread (unless you already have, and my
inbox is just being slow today).
--
PHP Internals - PHP
Hello internals,
About 3 weeks have passed since I announced the use_function RFC. A number of
issues were raised, and I believe all of them have been resolved at this point.
I would like to initiate the voting phase.
RFC: https://wiki.php.net/rfc/use_function
Patch:
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
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 rst...@tutteli.ch wrote:
Hi Igor,
Personally I like your RFC. I also like the fact that it is possible to
replace built-in functions where desired
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
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
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
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;
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.
--
PHP Internals - PHP Runtime Development
Hi Lars,
I don't really like the idea of such ghost features that don't actually do
anything. It sounds like it would just introduce wrong mappings. And since
those other constructs *do* share a namespace it technically wouldn't make
sense to make a distinction between them.
Any other
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:
Hi internals,
Since there's been no major objection to this proposed RFC, I will go ahead and
create it on the wiki. I will amend it to address some of the points that were
discussed so far.
Thanks,
Igor
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
No, I want to keep autoloading out of this proposal. It is way beyond the scope
of the namespacing issue and also incredibly complex.
That said, this RFC may be useful for implementing autoloading in the future,
as it addresses one of the things that makes function autoloading hard, which
is
Your solution is flawed, it would not allow autoloading a function that has the
same
(namespaced) name as a builtin.
Example:
// autoloadable function
namespace foo {
// make arg order consistent
function array_filter($callback, $input) {
return
Let me give you two specific cases where I think importing a function
significantly improves the readability of code.
A) Tiny libraries
I recently released a library that really just consists of two functions.
Those functions are named compose() and pipeline(), and the library is named
What's wrong with referencing one part of it? It can be as short as two
characters, and an an added bonus you won't suddenly have your strlen
overridden by somebody without you knowing it. Functions live in global
space, and there's a real lot of them, that's why importing them wasn't
Hello internals,
One of the shortcomings of namespaced functions in PHP is that it is not
possible to import them as you can do with classes and namespaces. For code
that is not in the same namespace as the function, you must always reference at
least one part of the namespace in order to call
Hi Internals,
When test driving PHP-5.5 I ran into issues with a change of unpack behaviour.
Archive_Tar which is used by pecl and pear (`pecl install`) uses unpack with
the a format character. On 5.4 it strips trailing NUL bytes, on 5.5 it does
not. There is a new Z format character that can
27 matches
Mail list logo
