On 2010-06-09 16:06:37 +0200, Ferenc Kovacs said:
In fact the uniq problem i see, is could be a name conflict like :
function Foo() {
// ...
}
class Foo() {
public __create() {
// ...
}
}
Foo(); // Instanciate the class or call the function ?
And I think that this is a much higher cost
Hi!
Let's me take the name __create() for this example :
We already have __construct for creating objects of class Foo, and if
those are objects of another class, you can always have a static factory.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900
>
>
> In fact the uniq problem i see, is could be a name conflict like :
>
> function Foo() {
> // ...
> }
>
> class Foo() {
> public __create() {
> // ...
> }
> }
>
> Foo(); // Instanciate the class or call the function ?
>
>
And I think that this is a much higher cost, that we gain.
If we w
On 2010-06-08 12:41:21 +0200, Johannes Schlüter said:
On Tue, 2010-06-08 at 12:23 +0200, Jacob Oettinger wrote:
Would it be equally simple to allow the syntax below?
$result = new ResultMaker()->getIt();
does this mean
$result = new (ResultMaker()->getIt());
or
$result = (new Resu
On 8 June 2010 17:28, Brian Moon wrote:
>> The operator that really determines this is 'new' - which is already
>> documented. So there isn't any ambiguity. Not to say that documenting
>> the other operators would be bad, just saying there's no ambiguity
>> here :)
>> Also, allowing "new (blah())
The operator that really determines this is 'new' - which is already
documented. So there isn't any ambiguity. Not to say that documenting
the other operators would be bad, just saying there's no ambiguity
here :)
Also, allowing "new (blah());" would be a fairly big BC break I'd say.
How? Mayb
On 8 June 2010 16:57, Ford, Mike wrote:
>> -Original Message-
>> From: Jacob Oettinger [mailto:ja...@oettinger.dk]
>> Sent: 08 June 2010 14:09
>>
>> On 08/06/2010, at 12.41, Johannes Schlüter wrote:
>>
>> > On Tue, 2010-06-08 at 12:23 +0200, Jacob Oettinger wrote:
>> >> Would it be equally
> -Original Message-
> From: Jacob Oettinger [mailto:ja...@oettinger.dk]
> Sent: 08 June 2010 14:09
>
> On 08/06/2010, at 12.41, Johannes Schlüter wrote:
>
> > On Tue, 2010-06-08 at 12:23 +0200, Jacob Oettinger wrote:
> >> Would it be equally simple to allow the syntax below?
> >>
> >> $r
> -Oorspronkelijk bericht-
> Van: Lars Schultz [mailto:lars.schu...@toolpark.com]
> Verzonden: dinsdag 8 juni 2010 16:04
> Aan: internals@lists.php.net
> Onderwerp: Re: [PHP-DEV] [RFC] Array Dereferencing
>
> >> $result = new ResultMaker()->getIt();
>
> > > $result = new ResultMaker()->getIt();
Isn't this issue just a matter of defining one thing as being correct
and then get on with it? There are lots of ambiguities in php's
grammar already.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://ww
$result = new ResultMaker()->getIt();
I know that this is not much of an argument, but it works the same way
in Javascript too, which is very convenient. The intended behaviour is
obvious...even though it could be (mis-)interpreted by php.
Lars
--
PHP Internals - PHP Runtime Development Ma
On 08/06/2010, at 12.41, Johannes Schlüter wrote:
> On Tue, 2010-06-08 at 12:23 +0200, Jacob Oettinger wrote:
>> Would it be equally simple to allow the syntax below?
>>
>> $result = new ResultMaker()->getIt();
>
> does this mean
>
>$result = new (ResultMaker()->getIt());
>
> or
>
>$
On Tue, 2010-06-08 at 12:23 +0200, Jacob Oettinger wrote:
> Would it be equally simple to allow the syntax below?
>
> $result = new ResultMaker()->getIt();
does this mean
$result = new (ResultMaker()->getIt());
or
$result = (new ResultMaker())->getIt();
I assume the later, but that i
Hi
This is great.
Would it be equally simple to allow the syntax below?
$result = new ResultMaker()->getIt();
and
$resultOfFunc = returnsFunc()();
I think would add consistency because it would allow direct operations on any
returned value. I agree that it is not the most reader friendly cod
On 08/06/10 02:14, Tig wrote:
Thanks!
Very happy about this :]
-Tig
+1 :D
--
Mark Skilbeck
mahcuz.com | gtk.php.net | pecl.php.net/cairo | docs.php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'll second that. I'm quite surprised that it was such a clean
addition to the parser. I owe you a few beers, Felipe.
-Joël
On Mon, Jun 7, 2010 at 9:16 PM, Jonathan Wage wrote:
> Thanks a bunch. This is a very nice improvement to PHP!
>
> - Jon
>
> On Mon, Jun 7, 2010 at 12:58 PM, Felipe Pena w
Thanks a bunch. This is a very nice improvement to PHP!
- Jon
On Mon, Jun 7, 2010 at 12:58 PM, Felipe Pena wrote:
> Hi all,
> I just edited the RFC page [1] about array dereferencing as now we have a
> patch for such.
>
> RFC page: http://wiki.php.net/rfc/functionarraydereferencing
>
> The patc
Thanks!
Very happy about this :]
-Tig
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2010/6/7 Stas Malyshev
> Hi!
>
>
> This is great. Did you check it on debug version though? I thought for
>> some reason you'd have to take care of freeing the value (which is
>> returned by function) after the expression is done, but maybe I missed
>> something. It's be also nice to see some mo
Hi!
This is great. Did you check it on debug version though? I thought for
some reason you'd have to take care of freeing the value (which is
returned by function) after the expression is done, but maybe I missed
something. It's be also nice to see some more assignment tests (also
maybe return-a
On Mon, Jun 7, 2010 at 9:22 PM, Pierre Joye wrote:
> hi Felipe,
>
> Great work! thanks :)
>
> Patches looks very good, builds on my tests system here.
>
> No objection for trunk :)
>
> Cheers,
>
> On Mon, Jun 7, 2010 at 6:58 PM, Felipe Pena wrote:
> > Hi all,
> > I just edited the RFC page [1] a
hi Felipe,
Great work! thanks :)
Patches looks very good, builds on my tests system here.
No objection for trunk :)
Cheers,
On Mon, Jun 7, 2010 at 6:58 PM, Felipe Pena wrote:
> Hi all,
> I just edited the RFC page [1] about array dereferencing as now we have a
> patch for such.
>
> RFC page:
On 6/7/10 9:58 AM, Felipe Pena wrote:
> Hi all,
> I just edited the RFC page [1] about array dereferencing as now we have a
> patch for such.
>
> RFC page: http://wiki.php.net/rfc/functionarraydereferencing
>
> The patch is simple, it just required to change the grammar file. I also
> added some
Hi!
RFC page: http://wiki.php.net/rfc/functionarraydereferencing
The patch is simple, it just required to change the grammar file. I also
added some tests in the patch.
This is great. Did you check it on debug version though? I thought for
some reason you'd have to take care of freeing the
24 matches
Mail list logo
