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,
>>
>> Thanks for the notes. I wi
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
--
PHP Internals - PHP Runtime Development Maili
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
On 20 August 2013 23:29, Igor Wiedler wrote:
> Hi Stas,
>
> Thanks for the notes. I will address these issues, hopefully during the next
> few days.
Nay news on that?
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
>
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 s
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
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\ here>
On Thu, Aug 15, 2013 at 3:11 PM, 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\;
> // in
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\; // in
java * is used for wildcard
Regards,
Marcello
On 15 Aug 2013, at 14:
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 wrote:
> Hey Igor,
>
> I
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!
> 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
Hi Stas,
2013/7/24 Stas Malyshev
> > 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
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
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 i
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
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
On 19.07.2013, at 21:29, Igor Wiedler 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.
2013/7/23 Igor Wiedler
> 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 wei
2013/7/23 Stas Malyshev
> 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 us
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
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
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,
Whats about constants?
Regards,
Sebastian
Am 19.07.2013 19:30 schrieb "Igor Wiedler" :
> 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
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
On 19.07.2013, at 21:29, Igor Wiedler 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
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
29 matches
Mail list logo
