On Sep 18, 2013, at 11:53 AM, Leigh 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 exist
at a
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 tool
ry. Please let me know if that
is not acceptable, in which case it can be extended.
Regards,
Igor
On Aug 15, 2013, at 4:08 PM, Igor Wiedler wrote:
> Hello internals,
>
> About 3 weeks have passed since I announced the use_function RFC. A number of
> issues were raised, and I beli
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 wrote:
> On 20 August 2013 23:29, Igor Wiedler wrote:
>> Hi Stas,
>>
>&g
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
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 wrote:
> Hi!
>
>> RFC: https://wiki.php.net/rfc/use_function
>> Patch: https://github.com/php/php-src/pull/388
>
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: https://github.com/php/php-
Hi Peter,
This *is* the [VOTE] thread. Am I missing something? :)
Regards,
Igor
On Aug 15, 2013, at 4:20 PM, Peter Cowburn 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 Runtime Development Mai
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: https://github.com/php/php-
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.
Anoth
"use function" does.
>
> Just an idea for pondering!
>
> Dan
>
>
>
> On Thu, Aug 8, 2013 at 2:44 PM, Michael Wallner wrote:
> On 8 August 2013 14:29, Igor Wiedler wrote:
> > Hi everyone,
> >
> > I just wanted to bump this topic, since ther
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" wrote:
> Hi Igor,
>
> Personally I like your RFC. I also like the fact that it is possible to
> "replace" built-in functions where desired by declari
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 Develop
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 wrote:
>
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 Ma
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,
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 wrote:
> Hi,
>
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 wrote:
> H
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 thoughts
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
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 \array_filter(
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 be
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: http://www.
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
"igorw/c
> 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
> con
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 c
27 matches
Mail list logo
