Re: [PHP-DEV] [RFC] Array Dereferencing
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, that we gain.
If we want this functionality, then Mathieu Suen's idea is better IMHO:
http://www.mail-archive.com/[email protected]/msg46764.html
eg. (new Foo())->bar()
Tyrael
Yes my only possible objection is that's less readable.
--
Alban Leroux
[email protected]
Web developper
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
>
>
> 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 want this functionality, then Mathieu Suen's idea is better IMHO:
http://www.mail-archive.com/[email protected]/msg46764.html
eg. (new Foo())->bar()
Tyrael
Re: [PHP-DEV] [RFC] Array Dereferencing
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 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
I think a pretty solution could be to introduce a new magic method like
__invoke() at the difference that's a static method not an instance method.
Let's me take the name __create() for this example :
class Foo {
public function __create() {
return new Foo();
}
public function doSomething() {
// ...
}
}
$foo = Foo()->doSomething();
This could be a very nice improvement :
- We could chain contruction and method call for classes with lot of setters.
- We could make factory design pattern more simplier.
- We no more need a name convention for singleton like getInstance().
- It's clean and easy to read.
- other ?
Personnaly, I actually use this in all of my class. And wrote always code like
this :
$class = Class::create()->setSomeThing()->doOtherThing();
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 ?
I hope this idea can help/inspire you.
Regards,
--
Alban Leroux
[email protected]
Web developper
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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());" 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 -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
On 8 June 2010 16:57, Ford, Mike wrote: >> -Original Message- >> From: Jacob Oettinger [mailto:[email protected]] >> 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? >> >> >> >> $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 -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Array Dereferencing
> -Original Message- > From: Jacob Oettinger [mailto:[email protected]] > 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? > >> > >> $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: [email protected] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Array Dereferencing
> -Oorspronkelijk bericht- > Van: Lars Schultz [mailto:[email protected]] > Verzonden: dinsdag 8 juni 2010 16:04 > Aan: [email protected] > 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 > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
> > > $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://www.php.net/unsub.php
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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 > >$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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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 On 07/06/2010, at 18.58, 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 tests in the patch. > > Any objection? Thought? Improvements? > > Thanks. > > -- > Regards, > Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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
Re: [PHP-DEV] [RFC] Array Dereferencing
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 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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 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
Re: [PHP-DEV] [RFC] Array Dereferencing
Thanks! Very happy about this :] -Tig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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 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
Re: [PHP-DEV] [RFC] Array Dereferencing
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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] 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > \o/ Tyrael
Re: [PHP-DEV] [RFC] Array Dereferencing
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: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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 tests in the patch. > > Any objection? Thought? Improvements? Looks good to me. The patch is nice and clean. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Array Dereferencing
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
