[RFC] Array Dereferencing

15 years ago by Stas Malyshev — view source — reply

unread

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 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-array-by-ref test).

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

15 years ago by Stas Malyshev — view source — reply

unread

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-array-by-ref test).

I checked it with debug and every case I could think of and it seems to
be working just fine, so - commit it to trunk :)

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

15 years ago by Felipe Pena — view source — reply

unread

2010/6/7 Stas Malyshev smalyshev@sugarcrm.com

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-array-by-ref test).

I checked it with debug and every case I could think of and it seems to be
working just fine, so - commit it to trunk :)

Yes, I always use ZTS+Debug build :P

I have committed the patch and added new tests.

Thanks guys for the feedback.

--
Regards,
Felipe Pena

15 years ago by tigger.on@gmail.com — view source — reply

unread

Thanks!

Very happy about this :]

-Tig

15 years ago by Mark Skilbeck — view source — reply

unread

Thanks!

Very happy about this :]

-Tig

+1 :D

--
Mark Skilbeck
mahcuz.com | gtk.php.net | pecl.php.net/cairo | docs.php.net

15 years ago by Rasmus Lerdorf — view source — reply

unread

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 tests in the patch.

Any objection? Thought? Improvements?

Looks good to me. The patch is nice and clean.

-Rasmus

15 years ago by Pierre Joye — view source — reply

unread

hi Felipe,

Great work! thanks :)

Patches looks very good, builds on my tests system here.

No objection for trunk :)

Cheers,

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 tests in the patch.

Any objection? Thought? Improvements?

Thanks.

--
Regards,
Felipe Pena

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

15 years ago by Ferenc Kovacs — view source — reply

unread

hi Felipe,

Great work! thanks :)

Patches looks very good, builds on my tests system here.

No objection for trunk :)

Cheers,

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 tests in the patch.

Any objection? Thought? Improvements?

Thanks.

--
Regards,
Felipe Pena

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--

\o/

Tyrael

15 years ago by Jonathan Wage — view source — reply

unread

Thanks a bunch. This is a very nice improvement to PHP!

Jon

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 tests in the patch.

Any objection? Thought? Improvements?

Thanks.

--
Regards,
Felipe Pena

--
Jonathan H. Wage
http://www.twitter.com/jwage

15 years ago by Joel Perras — view source — reply

unread

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

Thanks a bunch. This is a very nice improvement to PHP!

Jon

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 tests in the patch.

Any objection? Thought? Improvements?

Thanks.

--
Regards,
Felipe Pena

--
Jonathan H. Wage
http://www.twitter.com/jwage

--
I do know everything, just not all at once. It's a virtual memory problem.
You should follow me on Twitter: http://twitter.com/jperras

15 years ago by Jacob Oettinger — view source — reply

unread

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 code.

Jacob

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 tests in the patch.

Any objection? Thought? Improvements?

Thanks.

--
Regards,
Felipe Pena

15 years ago by johannes@schlueters.de — view source — reply

unread

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 is non-obvious as we allow

$result = new $class();

and

$resultOfFunc = returnsFunc()();

Having closures this might make sense. (While I don't want to debug code
like $foo("bar")[42]->do()("it"); )

Oh and obviously +1 on the original patch. ;-)

johannes

15 years ago by Jacob Oettinger — view source — reply

unread

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 is non-obvious as we allow

$result = new $class();

Yes the later. I do not see how the above makes it non-obvious.

As I see it the new operator will always instantiate the class name that comes after it. The name can be given as either a literal class name, or as a string variable or as a string variable in an array. It can not be given as a function or method that returns a string.

Regardless, it was the direct calling of a function (or invokable) returned from a function I think was a good idea for consistency.

Jacob

15 years ago by Ford — view source — reply

unread

-----Original Message-----
From: Jacob Oettinger [mailto:jacob@oettinger.dk]
Sent: 08 June 2010 14:09

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 is non-obvious as we allow

$result = new $class();

Yes the later. I do not see how the above makes it non-obvious.

I think the only problem with deciding which it means is that -> and () are not defined as operators in the PHP documentation, and as such do not have a clearly-defined precedence and associativity. In Javascript, "." (property access) and "()" (function call) both appear in the operator precedence table, so there are definite rules for ascertaining the meaning of such a construct.

Up until recently this probably hasn't really been a problem, as it's not been possible to write constructs that needed these rules to decipher them. However, with the previous addition of object access chaining, and now array dereferencing, the time has almost certainly come to add -> and () to the operator documentation, with appropriate precedence and associativity.

(Incidentally, other operators which are not documented in the "Operators" section, and probably should be, include :: (which is described in the "Classes and Objects" section as the "Scope Resolution Operator", and \ (namespace separator).)

Cheers!

Mike

Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Leeds Metropolitan University, C507, Civic Quarter Campus,
Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom
Email: m.ford@leedsmet.ac.uk
Tel: +44 113 812 4730

To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

15 years ago by Peter Lind — view source — reply

unread

-----Original Message-----
From: Jacob Oettinger [mailto:jacob@oettinger.dk]
Sent: 08 June 2010 14:09

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 is non-obvious as we allow

$result = new $class();

Yes the later. I do not see how the above makes it non-obvious.

I think the only problem with deciding which it means is that -> and () are not defined as operators in the PHP documentation, and as such do not have a clearly-defined precedence and associativity. In Javascript, "." (property access) and "()" (function call) both appear in the operator precedence table, so there are definite rules for ascertaining the meaning of such a construct.

Up until recently this probably hasn't really been a problem, as it's not been possible to write constructs that needed these rules to decipher them. However, with the previous addition of object access chaining, and now array dereferencing, the time has almost certainly come to add -> and () to the operator documentation, with appropriate precedence and associativity.

(Incidentally, other operators which are not documented in the "Operators" section, and probably should be, include :: (which is described in the "Classes and Objects" section as the "Scope Resolution Operator", and \ (namespace separator).)

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.

Regards
Peter

--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype

15 years ago by Brian Moon — view source — reply

unread

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? Maybe you don't understand what BC break means. Currently, new (
produces a parse error. So, no old code would ever be broken. That is
what a BC break is. A change to the system that breaks old code. New
code very often does not run on older versions of the parser.

Of course I think all this chaining stuff is for really really lazy
people that have more time to worry about the how cool their code looks
and don't have real jobs that actual require them to get things done. =)

Brian.
"In my day!"

15 years ago by Peter Lind — view source — reply

unread

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? Maybe you don't understand what BC break means. Currently, new (
produces a parse error. So, no old code would ever be broken. That is what a
BC break is. A change to the system that breaks old code. New code very
often does not run on older versions of the parser.

I do understand what BC break means - I was probably just too quick on
that one. I figured that allowing 'new (blahblah())' would introduce
ambiguity for handling parentheses in general with regards to 'new',
but I'm probably wrong.

Regards
Peter

--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype

15 years ago by Lars Schultz — view source — reply

unread

$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

15 years ago by troels knak-nielsen — view source — reply

unread

$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

15 years ago by Dennis Haarbrink — view source — reply

unread

-----Oorspronkelijk bericht-----
Van: Lars Schultz [mailto:lars.schultz@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();

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

--

I agree, this is obviously the intended behaviour.
As long as the door is still open to do:

$result = new (ResultMaker()->getIt());

To create an object of the class returned by the getIt() method.

-Dennis

[RFC] Array Dereferencing

I checked it with debug and every case I could think of and it seems to be working just fine, so - commit it to trunk :)

Mike

I checked it with debug and every case I could think of and it seems to
be working just fine, so - commit it to trunk :)