Re: [PHP-DEV] Re: Hold off 5.4
On Fri, 26 Nov 2010, Kalle Sommer Nielsen wrote: 2010/11/25 Zeev Suraski z...@zend.com: I think that skipping to a major version is a good idea. Two key reasons I think that: 1. It'll help us break the evil spell of the 6 version number. Honestly, I'm not so certain we'll have major engine rewrites the size of what we've seen in PHP 3/4/5 going forward. Sure, I have a track record for saying that in the past before PHP 5, but this time I *really* think we've reached an evolutionary stage :). Even if I'm wrong and we'd have a major rewrite happening, I don't think any of us is seeing it any time soon. I also think that its appealing to skip to version 6 to break that spell once and for all. I think it's a bad idea. We'd just be scaring users because new major version = break. We're not breaking a thing (or atleast, try not to). And think about distrbutions that'd want to wait til 6.1 or something. We should reserve major versions for BC breaks. Just like we've always done. I don't see the point of changing this, as it feels to me that you just want to change it because you want to change it. Now, *if*, we would introduce breaking changes, skipping 6 might be a good plan (and go straight to 7), but I don't see any sort of compelling reason why you'd want to go to 6/7 now. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 25 Nov 2010, Pierre Joye wrote: On Thu, Nov 25, 2010 at 3:05 PM, Derick Rethans der...@php.net wrote: This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). Four branches? Are you going to help? I'd to ask you to stop to say that in every 2nd person. What have you done lately to help anyway? I don't understand why you're being so agressive. It was a honest question. More branches need more people to maintain it. And what is the problem with asking people for help? Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Friday, November 26, 2010 3:03 AM To: Ilia Alshanetsky Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 That can always be done later. Why do it later if we could do it now? :) Can you share some of the major things you think would constitute a stronger reason to switch to 7 (or 11) than what we have in 5.4, that we have in the pipeline? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
-Original Message- From: Derick Rethans [mailto:der...@php.net] Sent: Friday, November 26, 2010 12:00 PM To: Kalle Sommer Nielsen Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 On Fri, 26 Nov 2010, Kalle Sommer Nielsen wrote: 2010/11/25 Zeev Suraski z...@zend.com: I think that skipping to a major version is a good idea. Two key reasons I think that: 1. It'll help us break the evil spell of the 6 version number. Honestly, I'm not so certain we'll have major engine rewrites the size of what we've seen in PHP 3/4/5 going forward. Sure, I have a track record for saying that in the past before PHP 5, but this time I *really* think we've reached an evolutionary stage :). Even if I'm wrong and we'd have a major rewrite happening, I don't think any of us is seeing it any time soon. I also think that its appealing to skip to version 6 to break that spell once and for all. I think it's a bad idea. We'd just be scaring users because new major version = break. We're not breaking a thing (or atleast, try not to). And think about distrbutions that'd want to wait til 6.1 or something. I *think* that a good message is always easy to convey. 'Moving from 5.3 to 7.0 is a no brainer and is effortless' is easy to convey. Of course, I could be wrong... We should reserve major versions for BC breaks. Just like we've always done. I don't see the point of changing this, as it feels to me that you just want to change it because you want to change it. Even if we don't move a major version (or two) now, I think we should reconsider that major-version == major-breakage linkage. I'm not sure it holds true any longer, and may push us to be stuck in the 5.x realm for a very long time (as a matter of fact, we already are - since mid 2004 - with no change in sight). Now, *if*, we would introduce breaking changes, skipping 6 might be a good plan (and go straight to 7), but I don't see any sort of compelling reason why you'd want to go to 6/7 now. No compelling reason. It's almost at the 'why not' level, and the only two reasons I have are the ones I stated in my previous email. We could go with 5.4 and the world won't stop spinning, I just think that going with 7.0 will have some benefits. Zeev
Re: [PHP-DEV] Re: Hold off 5.4
On Fri, Nov 26, 2010 at 4:46 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Friday, November 26, 2010 3:03 AM To: Ilia Alshanetsky Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 That can always be done later. Why do it later if we could do it now? :) Can you share some of the major things you think would constitute a stronger reason to switch to 7 (or 11) than what we have in 5.4, that we have in the pipeline? Wait, why do you want a major version for something that does not break BC, that only adds a couple of features (even long awaited like traits)? I don't see one. For a new major version I would rather first sort out the RFC, get the next 5.x out and then begin the discussions, designs, etc. Or are you looking to re do all the mistakes and pains we experiment with 5.3.0 and ex.6.0.0? I won't go down this way. About the let drop the number 6 thing, that's just plain marketing and really, that's the least problem our users have, or that we have. Cheers, -- 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] Re: Hold off 5.4
On Fri, Nov 26, 2010 at 6:21 PM, Pierre Joye pierre@gmail.com wrote: On Fri, Nov 26, 2010 at 4:46 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Friday, November 26, 2010 3:03 AM To: Ilia Alshanetsky Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 That can always be done later. Why do it later if we could do it now? :) Can you share some of the major things you think would constitute a stronger reason to switch to 7 (or 11) than what we have in 5.4, that we have in the pipeline? Wait, why do you want a major version for something that does not break BC, that only adds a couple of features (even long awaited like traits)? I don't see one. To make it clear, I should have written: A release not breaking BC, as we can have a 5.4 release without BC breaks and with clear decisions about what we want to have in. -- 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] Re: Hold off 5.4
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Friday, November 26, 2010 7:21 PM To: Zeev Suraski Cc: Ilia Alshanetsky; Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 On Fri, Nov 26, 2010 at 4:46 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Friday, November 26, 2010 3:03 AM To: Ilia Alshanetsky Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 That can always be done later. Why do it later if we could do it now? :) Can you share some of the major things you think would constitute a stronger reason to switch to 7 (or 11) than what we have in 5.4, that we have in the pipeline? Wait, why do you want a major version for something that does not break BC, that only adds a couple of features (even long awaited like traits)? I don't see one. For a new major version I would rather first sort out the RFC, get the next 5.x out and then begin the discussions, designs, etc. Or are you looking to re do all the mistakes and pains we experiment with 5.3.0 and ex.6.0.0? I won't go down this way. About the let drop the number 6 thing, that's just plain marketing and really, that's the least problem our users have, or that we have. I'll begin again by saying I don't feel strongly about renaming 5.4 as 7.0, but there are some important points worth bringing up: 1. The motivation for changing major version numbers was *never* BC breakage. It was substantial language changes/additions and sometimes substantial underlying engine changes. BC breakage was typically a side effect of that. 2. Marketing does not equate Evil. There's nothing bad about making good moves that improve the perception of PHP in its userbase or the world at large. Turning the current trunk version into a major version can be perceived as a 'marketing' move - but that doesn't mean it's not legit. Other than showing that the PHP project is moving along, there's also the warm-fuzzy-feeling aspect, and based on the last couple of days it's clear I'm not the only one that feels bad about being stuck in 5.x for over 6 years with no change in sight. 3. The motivation to skip 6 doesn't stem from marketing at all. The main motivation is that there's a VERY concrete perception amongst many users about what PHP 6 is. It's unlikely that PHP 6 will actually be that. Skipping this version makes perfect sense from just about any POV I can think of. That's actually one thing I do feel more strongly about - we should probably not reuse the version number 6.0 for something that's completely different than what we've been talking about for several years, whether it's now or anytime in the future. What we call that version, whether it's PHP 5.4, PHP 7.0 or even PHP 3000, shouldn't change the way we discuss contents for it. The fact I want to call the very same thing we intend to release with a different name has absolutely nothing to do with the pains we experimented with 5.3 or 6.0. We can agree to disagree (and again - whatever - I'm fine with 5.4!), but no need to invent unrelated horror stories :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski z...@zend.com wrote: I'll begin again by saying I don't feel strongly about renaming 5.4 as 7.0, but there are some important points worth bringing up: 1. The motivation for changing major version numbers was *never* BC breakage. It was substantial language changes/additions and sometimes substantial underlying engine changes. BC breakage was typically a side effect of that. No, but it was the main reasons. 2. Marketing does not equate Evil. There's nothing bad about making good moves that improve the perception of PHP in its userbase or the world at large. Turning the current trunk version into a major version can be perceived as a 'marketing' move - but that doesn't mean it's not legit. Other than showing that the PHP project is moving along, there's also the warm-fuzzy-feeling aspect, and based on the last couple of days it's clear I'm not the only one that feels bad about being stuck in 5.x for over 6 years with no change in sight. Right, and it was not meant badly. Only that it has no technical or features-wise reasons to do so but brings its lots of risks with it. 3. The motivation to skip 6 doesn't stem from marketing at all. The main motivation is that there's a VERY concrete perception amongst many users about what PHP 6 is. Leaving the very small conference crowd for a second: nobody never ever heard of php6 before the total fiasco a couple of months ago. What we call that version, whether it's PHP 5.4, PHP 7.0 or even PHP 3000, shouldn't change the way we discuss contents for it. The fact I want to call the very same thing we intend to release with a different name has absolutely nothing to do with the pains we experimented with 5.3 or 6.0. Let say I know us too good and I don't think moving it to a major version will be of any help. We can agree to disagree (and again - whatever - I'm fine with 5.4!), Right, but I really don't like that the feelings, wishes, requests and will of most of the active developers seem to be totally ignored by a couple of us. That's not what I like to see in a project like php.net. There is clearly a need to change the way we work, communicate and decide things (be releases, features, etc.). Like it or not, that's a fact. Other example, you do not want this type hinting, but what do you do to change that? Why do you simply ignore it? but no need to invent unrelated horror stories :) Invent horror stories? Maybe you should take a bit more parts of the day to day releases and development to see that they are not invented stories :). Cheers, -- 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
[PHP-DEV] [RFC] new foo()-bar()
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
--
Regards,
Felipe Pena
Re: [PHP-DEV] [RFC] new foo()-bar()
+1
Seems like a handy change and the patch is quite manageable.
On Fri, Nov 26, 2010 at 2:36 PM, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
On Fri, Nov 26, 2010 at 14:36, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
I'm all for it, Felipe. Chaining like that would really come in
handy in several situations of which I can think right off the top of
my head even.
--
/Daniel P. Brown
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
On Fri, 2010-11-26 at 17:36 -0200, Felipe Pena wrote: var_dump(new foo()-bar()-x); // string(3) PHP It has some readability issues. One might assume it is new (foo()-bar()-x) not (new foo())-bar()-x As there is a mandatory space between new and its operand and no space in front of the object operator and we allow non-constant operands to new. So what is new $bar-foo(); ? If I read the patch correctly this is valid and evaluated as (new $bar)-foo(); johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
On Fri, Nov 26, 2010 at 8:36 PM, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
--
Regards,
Felipe Pena
I like it, and it is a good pair with the new array dereferencing, so
hopefully I don't have to create temp variables anymore \o/
Tyrael
Re: [PHP-DEV] [RFC] new foo()-bar()
On 26 November 2010 20:36, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
It seems fairly handy and I've been in situations where I wanted to do
something like that - in fact, I use factories to achieve something
similar.
However, the more I use it, the more it feels like introducing code
smells into my code. You're essentially instantiating an object only
to immediately throw it away. That means you don't actually need the
object at all, you should probably be looking for static methods or
class properties. Trying to avoid statics by introducing a way to
instantiate and throw away objects in the same statement feels a lot
like reinventing OOP while adding overhead.
Anyway, just a personal observation. I generally favour the way that
PHP allows you to dig your own grave (i.e. I love the freedom of the
language), so as a developer I would probably favour this as well,
though I find it mainly a way to introduce hacks.
Regards
Peter
--
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
On Fri, Nov 26, 2010 at 9:25 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 26 November 2010 20:36, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its
properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
It seems fairly handy and I've been in situations where I wanted to do
something like that - in fact, I use factories to achieve something
similar.
However, the more I use it, the more it feels like introducing code
smells into my code. You're essentially instantiating an object only
to immediately throw it away. That means you don't actually need the
object at all, you should probably be looking for static methods or
class properties. Trying to avoid statics by introducing a way to
instantiate and throw away objects in the same statement feels a lot
like reinventing OOP while adding overhead.
Anyway, just a personal observation. I generally favour the way that
PHP allows you to dig your own grave (i.e. I love the freedom of the
language), so as a developer I would probably favour this as well,
though I find it mainly a way to introduce hacks.
1, I have to use a non-trivial library or module for a simple task, and I
don't want to write 20 line of code, and introduce 4 helper variable.
2. I want to get from point 1 to point 5 but I'm not interested in the steps
in-between (classical method chaining), but sadly one of the steps requires
object instantiation.
Tyrael
Re: [PHP-DEV] [RFC] new foo()-bar()
On 26 November 2010 21:37, Ferenc Kovacs i...@tyrael.hu wrote:
On Fri, Nov 26, 2010 at 9:25 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 26 November 2010 20:36, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its
properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
It seems fairly handy and I've been in situations where I wanted to do
something like that - in fact, I use factories to achieve something
similar.
However, the more I use it, the more it feels like introducing code
smells into my code. You're essentially instantiating an object only
to immediately throw it away. That means you don't actually need the
object at all, you should probably be looking for static methods or
class properties. Trying to avoid statics by introducing a way to
instantiate and throw away objects in the same statement feels a lot
like reinventing OOP while adding overhead.
Anyway, just a personal observation. I generally favour the way that
PHP allows you to dig your own grave (i.e. I love the freedom of the
language), so as a developer I would probably favour this as well,
though I find it mainly a way to introduce hacks.
1, I have to use a non-trivial library or module for a simple task, and I
don't want to write 20 line of code, and introduce 4 helper variable.
If it's a one-off, then I really don't see the problem. If you're
facing it again, write a facade.
2. I want to get from point 1 to point 5 but I'm not interested in the steps
in-between (classical method chaining), but sadly one of the steps requires
object instantiation.
If it's your code, then why are you not simplifying it? What's the
point of writing code that you have to go through in five steps? Why
not write a wrapper method?
The reasons presented sounds quite like I want to be able write
hacks easier rather than I want to fix an actual problem. I.e.
there are solutions for this already that use OOP principles.
That said, this fix may very well address other situations :)
Regards
Peter
--
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
2010/11/26 Johannes Schlüter johan...@schlueters.de
On Fri, 2010-11-26 at 17:36 -0200, Felipe Pena wrote:
var_dump(new foo()-bar()-x); // string(3) PHP
It has some readability issues. One might assume it is
new (foo()-bar()-x)
not
(new foo())-bar()-x
As there is a mandatory space between new and its operand and no space
in front of the object operator and we allow non-constant operands to
new.
So what is
new $bar-foo();
? If I read the patch correctly this is valid and evaluated as
(new $bar)-foo();
johannes
new foo()-bar() should be read as: (new foo())-bar().
And using variable:
new $bar-y()-x should be read as: (new ($bar-y)())-x.
?php
class foo {
public $x = 1;
}
class bar {
public $y = 'foo';
}
$bar = new bar;
var_dump(new $bar-y()-x); // 1
?
I.e. just as it is nowdays.
--
Regards,
Felipe Pena
Re: [PHP-DEV] [RFC] new foo()-bar()
On Fri, Nov 26, 2010 at 9:46 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 26 November 2010 21:37, Ferenc Kovacs i...@tyrael.hu wrote:
On Fri, Nov 26, 2010 at 9:25 PM, Peter Lind peter.e.l...@gmail.com
wrote:
On 26 November 2010 20:36, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its
properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
It seems fairly handy and I've been in situations where I wanted to do
something like that - in fact, I use factories to achieve something
similar.
However, the more I use it, the more it feels like introducing code
smells into my code. You're essentially instantiating an object only
to immediately throw it away. That means you don't actually need the
object at all, you should probably be looking for static methods or
class properties. Trying to avoid statics by introducing a way to
instantiate and throw away objects in the same statement feels a lot
like reinventing OOP while adding overhead.
Anyway, just a personal observation. I generally favour the way that
PHP allows you to dig your own grave (i.e. I love the freedom of the
language), so as a developer I would probably favour this as well,
though I find it mainly a way to introduce hacks.
1, I have to use a non-trivial library or module for a simple task, and
I
don't want to write 20 line of code, and introduce 4 helper variable.
If it's a one-off, then I really don't see the problem. If you're
facing it again, write a facade.
2. I want to get from point 1 to point 5 but I'm not interested in the
steps
in-between (classical method chaining), but sadly one of the steps
requires
object instantiation.
If it's your code, then why are you not simplifying it? What's the
point of writing code that you have to go through in five steps? Why
not write a wrapper method?
The reasons presented sounds quite like I want to be able write
hacks easier rather than I want to fix an actual problem. I.e.
there are solutions for this already that use OOP principles.
Sorry, I don't have the time and/or patience to fix every code out there,
which I might happen to come across in a project. :)
That said, this fix may very well address other situations :)
sure thing, I just told a(two) use-case from the top of my head.
Tyrael
RE: [PHP-DEV] Re: Hold off 5.4
Only that it has no technical or features- wise reasons to do so Substantial engine level improvements and a couple of new language level features (it's pushing it a bit, I agree, but not that much) but brings its lots of risks with it. I fail to see how changing a version number brings any risk at all. Leaving the very small conference crowd for a second: nobody never ever heard of php6 before the total fiasco a couple of months ago. I disagree. Google for PHP 6. I've received tons of questions about it from non-core-community attendees to conferences. I've received countless questions about it from Japanese and Chinese users. It's out there. If I had to bet based on my experience with users, there are a lot more people that know what PHP 6 was supposed to be than people who know its plans were scrapped. I'll reply to some of your personal rant in person. It doesn't belong here... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Fri, Nov 26, 2010 at 9:58 PM, Zeev Suraski z...@zend.com wrote: I disagree. Google for PHP 6. I've received tons of questions about it from non-core-community attendees to conferences. that's the crowd I referenced to. The users I discuss too, in locale conference, UG, enterprises, etc. never heard or only vaguely about php6. Or they heard about it while seeing a book called PHP 6 and mysql 6 or something stupid like that ;). I've received countless questions about it from Japanese and Chinese users. It's out there. If I had to bet based on my experience with users, there are a lot more people that know what PHP 6 was supposed to be than people who know its plans were scrapped. Same here, and that's one of the pandora box I want to open again. Only not now, but not necessary in 2 years either. Hence the importance of the RFC and clear, transparent process first. I'll reply to some of your personal rant in person. It doesn't belong here... Rants? I only replied to invented story. Cheers, -- 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] Re: Hold off 5.4
that's the crowd I referenced to. The users I discuss too, in locale conference, UG, enterprises, etc. never heard or only vaguely about php6. Or they heard about it while seeing a book called PHP 6 and mysql 6 or something stupid like that ;). I've yet to meet someone in the last few years who knew about the PHP 6 project, and wasn't aware it was about unicoding PHP... People care about the roadmap of the products they're using. I'm not sure why you would think that the multi-year flagship version of PHP would remain a best-kept-secret. If you google for PHP 6 it's clear beyond a reasonable doubt.. I've received countless questions about it from Japanese and Chinese users. It's out there. If I had to bet based on my experience with users, there are a lot more people that know what PHP 6 was supposed to be than people who know its plans were scrapped. Same here, and that's one of the pandora box I want to open again. Only not now, but not necessary in 2 years either. Hence the importance of the RFC and clear, transparent process first. Given what I know about why we failed, and what alternatives exist, I wouldn't hold my breath. I'm too old to say it'll never happen, but I think I can say with a very high degree of confidence the chances of it happening within the next two years are very slim. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Zeev Suraski wrote: that's the crowd I referenced to. The users I discuss too, in locale conference, UG, enterprises, etc. never heard or only vaguely about php6. Or they heard about it while seeing a book called PHP 6 and mysql 6 or something stupid like that;). I've yet to meet someone in the last few years who knew about the PHP 6 project, and wasn't aware it was about unicoding PHP... People care about the roadmap of the products they're using. I'm not sure why you would think that the multi-year flagship version of PHP would remain a best-kept-secret. If you google for PHP 6 it's clear beyond a reasonable doubt.. At the time that PHP5 was released PHP6 was being documented and roadmaped as the unicode path which would be in alpha 'in a couple of years time'. THAT is the documentation that was used as the basis of several premature books on PHP6. http://www.php.net/~derick/meeting-notes.html from the November 2005 meeting in Paris is what we were all expecting to follow PHP5 since PHP5 did NOT address the unicode problem that was well understood even back then -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Fri, Nov 26, 2010 at 2:27 PM, Pierre Joye pierre@gmail.com wrote: On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski z...@zend.com wrote: 3. The motivation to skip 6 doesn't stem from marketing at all. The main motivation is that there's a VERY concrete perception amongst many users about what PHP 6 is. Leaving the very small conference crowd for a second: nobody never ever heard of php6 before the total fiasco a couple of months ago. Nobody ever heard of PHP 6? If you visit amazon.com and try search for php 6, you'll see no less than 6 books (I stopped counting) all containing PHP 6 in the title. In the general PHP list, you'll see that developers reference PHP 6 when speaking of how to handle unicode, and how you will handle unicode in the future. If you search Google for php 6, you'll be greeted with hundreds of blog posts speaking of how to prepare for the coming changes in PHP 6 or other aspects of its development. The title PHP 6 has much baggage. The perception in the general community is strong and pervasive, and it certainly is not limited to a small conference crowd. Developers have strongly conceived expectations about what PHP 6 will entail, and as the releases creep towards an eventual 6.0, the growing divergence between the expectations and the actual releases will likely cause confusion and frustration. Given the expectations, the strength of the enhancements coming in this next release (significant engine rewrites, traits, APC, etc.), and the trend in nomenclature for software versions, I believe the case for jumping to a 7.0 release makes sense. I'm not an active contributor to the PHP core and I have no patches to my name, so I'm not sure what my vote is worth. However, I do actively help those on the general mailing list who are trying to learn basic PHP or are trying to troubleshoot new code, and it's the general developers in userland who will benefit from the most from the clear separation from the expectations. Adam -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
RE: [PHP-DEV] [RFC] new foo()-bar()
November-26-10 2:36 PM, Felipe Pena writes:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its
properties on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
Nice. I have use for this.
Some readability issues may arise but nothing that can't be
overcome with some common sense.
Best Regards,
Mike Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
On 11/26/2010 2:36 PM, Felipe Pena wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
I fully support this patch. This is something PHP has needed for a long
time.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
On Fri, 26 Nov 2010 20:25:32 -, Peter Lind peter.e.l...@gmail.com wrote: It seems fairly handy and I've been in situations where I wanted to do something like that - in fact, I use factories to achieve something similar. However, the more I use it, the more it feels like introducing code smells into my code. You're essentially instantiating an object only to immediately throw it away. Not necessarily; you could be calling the method for the collateral effects and that method return the object itself. This is not that uncommon. +1 -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
On Friday, November 26, 2010, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Fri, 26 Nov 2010 20:25:32 -, Peter Lind peter.e.l...@gmail.com wrote: It seems fairly handy and I've been in situations where I wanted to do something like that - in fact, I use factories to achieve something similar. However, the more I use it, the more it feels like introducing code smells into my code. You're essentially instantiating an object only to immediately throw it away. Not necessarily; you could be calling the method for the collateral effects and that method return the object itself. This is not that uncommon. And I can do that today with a factory pattern, if I want to. Anyway, I don't want to argue against the feature, as it will just introduce a slightly shorter version of something we can already do. -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
On Fri, Nov 26, 2010 at 2:36 PM, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
--
Regards,
Felipe Pena
Felipe, you're on a roll :) It's great!
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
Re: [PHP-DEV] [RFC] new foo()-bar()
+1
Good job felipe
On 26 November 2010 14:36, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
--
Regards,
Felipe Pena
Re: [PHP-DEV] [RFC] new foo()-bar()
Hi Felipe
2010/11/26 Felipe Pena felipe...@gmail.com:
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
huge +1 from me ;-) It might be worth adding function call chaining
with dereferencing and instance method call chaning, like $a =
function(){ return function(){ echo 'Hello'; }; }; $a()();
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
Hi!
huge +1 from me ;-) It might be worth adding function call chaining
with dereferencing and instance method call chaning, like $a =
function(){ return function(){ echo 'Hello'; }; }; $a()();
See: http://wiki.php.net/rfc/fcallfcall
--
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] new foo()-bar()
+1 :)
On Fri, Nov 26, 2010 at 8:36 PM, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
--
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] Re: Hold off 5.4
On 11/26/10 12:58 PM, Zeev Suraski wrote: Only that it has no technical or features- wise reasons to do so Substantial engine level improvements and a couple of new language level features (it's pushing it a bit, I agree, but not that much) I think the next major version should be used to drop a bunch of deprecated features and to clean up some things. That's going to take a bit of time to figure out and agree on which means traits and the performance improvements are going to sit around unused for longer than if we get an interim version out there quicker. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
On Friday, November 26, 2010, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Fri, 26 Nov 2010 20:25:32 -, Peter Lind peter.e.l...@gmail.com wrote: It seems fairly handy and I've been in situations where I wanted to do something like that - in fact, I use factories to achieve something similar. However, the more I use it, the more it feels like introducing code smells into my code. You're essentially instantiating an object only to immediately throw it away. Not necessarily; you could be calling the method for the collateral effects and that method return the object itself. This is not that uncommon. And I can do that today with a factory pattern, if I want to. Anyway, I don't want to argue against the feature, as it will just introduce a slightly shorter version of something we can already do. -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
It's nice but as long as the browsers don't implement it natively then it's less useful for server to client communication. Of course can still be quite useful with custom I/O or data sources that implement it natively i.e. mongodb. -Original Message- From: Ilia Alshanetsky [mailto:i...@prohost.org] Sent: Thursday, November 25, 2010 4:16 PM To: Pierre Joye Cc: Jonah H. Harris; Andi Gutmans; internals@lists.php.net Subject: Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize()) Just read over the BSON spec, looks fairly interesting, the only bit that appears to be missing for PHP purposes is object support. We would need to introduce custom type on top of standard BSON. However from compactness and consistency standpoint it looks fairly appealing. On Thu, Nov 25, 2010 at 2:51 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Nov 25, 2010 at 8:47 PM, Jonah H. Harris jonah.har...@gmail.com wrote: On Thu, Nov 25, 2010 at 2:14 PM, Pierre Joye pierre@gmail.com wrote: For the record here, igbinary is a very good example of such optimization: http://opensource.dynamoid.com/ igbinary is a nice extension indeed. However, for those of us who have environments which include multiple programming languages, custom serializations become a PITA. As such, we generally go with something more portable such as Avro or straight JSON. Awhile back, I had done some work rewriting the JSON serialization functions to use the fast (and BSD licensed) yajl JSON parser (https://github.com/lloyd/yajl). Initial benchmarks showed a 4-7% performance improvement in serialization/deserialization. Good point indeed. That makes me think about bson (http://bsonspec.org/), which is used by mongodb for example. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
