You can write String class all by yourself, put it on github and once
virtually
everybody is using it, we'd gladly discuss including it as a standard
extension.
In userland we can only do something like
$str = new String('my_string_class');
echo $str-length();
But that's useless.
It would
Hi,
There’s something that I’m not quite following regarding open votes.
Why are we saying that ‘votes will end no sooner than X’, instead of
actually saying when they *will* end?
If there’s no clear end date for a vote, when do we declare than a vote is
over? Is it in a specific point in
Hi,
Wouldn't it make more sense to have the ini consistent with the
function name, sys_temp_dir?
Yes, I think it would. Alex, could you change it?
You're right. It's changed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hi,
On Mon, Jan 28, 2013 at 10:22 AM, Zeev Suraski z...@zend.com wrote:
Hi,
There’s something that I’m not quite following regarding open votes.
Why are we saying that ‘votes will end no sooner than X’, instead of
actually saying when they *will* end?
If there’s no clear end date for
Hi,
Le Mon, 28 Jan 2013 11:22:52 +0200, Zeev Suraski a écrit :
Regardless, an
‘open ended’
voting period is unacceptable IMHO.
I agree with that. An update of the voting rfc (https://wiki.php.net/rfc/
voting) should be made.
However one week only seems a little shorter in my opinion to
On 01/28/2013 10:22 AM, Zeev Suraski wrote:
My suggestion is for voting periods to be limited to one week, regardless
of the topic. It should be more than enough. Regardless, an ‘open ended’
voting period is unacceptable IMHO.
Whatever the voting period is, IMHO the most important thing
My suggestion is for voting periods to be limited to one week,
regardless of the topic. It should be more than enough. Regardless,
an 'open
ended'
voting period is unacceptable IMHO.
You were one of the person who requested to have at least two weeks, so
nobody can miss a vote due to
hi,
On Mon, Jan 28, 2013 at 11:57 AM, Zeev Suraski z...@zend.com wrote:
My suggestion is for voting periods to be limited to one week,
regardless of the topic. It should be more than enough. Regardless,
an 'open
ended'
voting period is unacceptable IMHO.
You were one of the person who
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Monday, January 28, 2013 1:07 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Voting periods
hi,
On Mon, Jan 28, 2013 at 11:57 AM, Zeev Suraski z...@zend.com wrote:
My suggestion is for
On Mon, Jan 28, 2013 at 12:19 PM, Zeev Suraski z...@zend.com wrote:
I will add a vote on that in the voting RFC, as un update, so we will a
clear(er)
position for the next RFCs.
OK, please put a one week as an option too. To put things in perspective,
elections that effect the fate of
On 1/28/2013 5:19 AM, Zeev Suraski wrote:
I feel that this is what was done in this particular case, not the
other way around. That what brought me to bring up that subject here
in the first place. This particular RFC was the only RFC where I
noticed this weird 'no sooner than' language, and
On 1/28/2013 2:09 AM, Christian Stoller wrote:
In userland we can only do something like
$str = new String('my_string_class');
echo $str-length();
But that's useless.
It would be great if method calls on primitive types could be supported, like
in Nikic' proof of concept
On 28 January 2013 12:03, Clint Priest cpri...@zerocue.com wrote:
If you're still worried about this making it in, don't worry. Nikita and I
have given up, to the determinant of the community.
Then please close the voting.
--
PHP Internals - PHP Runtime Development Mailing List
To
Am 28.01.2013 12:19, schrieb Zeev Suraski:
OK, please put a one week as an option too. To put things in perspective,
elections that effect the fate of billions of people typically end in
24hrs.
But they sometimes require weeks of analysing punch cards ;-)
--
Sebastian Bergmann
hi Clint, Zeev,
On Mon, Jan 28, 2013 at 1:03 PM, Clint Priest cpri...@zerocue.com wrote:
On 1/28/2013 5:19 AM, Zeev Suraski wrote:
I feel that this is what was done in this particular case, not the other
way around. That what brought me to bring up that subject here in the first
place. This
Zeev, for one, was one of them asking to have a 2/3 majority for any
language
related RFC. That's what applies to this RFC, and it is, as of now,
accepted. I don't
see how the vote is remotely close to a tie.
Are you talking about https://wiki.php.net/rfc/propertygetsetsyntax-v1.2?
There are
-Original Message-
From: Zeev Suraski [mailto:z...@zend.com]
Sent: Monday, January 28, 2013 3:00 PM
To: 'Pierre Joye'; 'Clint Priest'
Cc: 'PHP internals'
Subject: RE: [PHP-DEV] Voting periods
Zeev, for one, was one of them asking to have a 2/3 majority for any
language related
On Mon, Jan 28, 2013 at 2:00 PM, Zeev Suraski z...@zend.com wrote:
Zeev, for one, was one of them asking to have a 2/3 majority for any
language
related RFC. That's what applies to this RFC, and it is, as of now,
accepted. I don't
see how the vote is remotely close to a tie.
Are you talking
I mean more no matter if it is or not, but the result is not tie
anyway, accepted
or not.
I find the way things are being done right now as a bad thing. There is
a time for
discussions and argumentations, and there is a time for votes. Coming in
with
things like that does not give me a good
On 1/28/2013 6:12 AM, Peter Cowburn wrote:
On 28 January 2013 12:03, Clint Priest cpri...@zerocue.com wrote:
If you're still worried about this making it in, don't worry. Nikita and I
have given up, to the determinant of the community.
Then please close the voting.
Since there is no maximum
+1 from that, fortunately since it's an extension it won't be subject to a
vote, you can use it or not. :) The core seems to be heavily protected by
the core developers.
As an APC user, I would be also fine with an extension :-)
@pierre Would it be possible to get windows builds from
On Sun, 20 Jan 2013 20:17:05 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt
wrote:
I've opened the vote for the remove calls from incompatible context
RFC:
https://wiki.php.net/rfc/incompat_ctx#vote
The RFC has been accepted unanimously. I'll implement it shortly. The
change is trivial
A large majority has been in favor of the One year with security
fixes only, announce with5.5 final release option.
That means PHP 5.3 end of life (no release, no support, etc.) will
happen exactly one year after the release of PHP 5.5.0-stable. The
announce of the exact date will be done at the
Holy crap, how did you sneak this through..
my apologies for deleting the = vote, but i could not work out how to revert it.
But this is a core php feature, for anyone who does not use traits We use
this quite a bit, it may not be for purists, but it has worked perfectly for
years. This
On Mon, 28 Jan 2013 15:17:21 +0100, Alan Knowles a...@roojs.com wrote:
my apologies for deleting the = vote, but i could not work out how to
revert it.
No problem, the result is still available at
https://wiki.php.net/rfc/incompat_ctx?rev=1359379541
I don't know want to know what you
On Mon, Jan 28, 2013 at 3:17 PM, Alan Knowles a...@roojs.com wrote:
Holy crap, how did you sneak this through..
what do you mean by sneak? it was proposed and announced in the usual
channels.
my apologies for deleting the = vote, but i could not work out how to
revert it.
no problem,
I was trying to vote against, for what it's worth.
It's a major bc break with no obvious value, and what appears to be 7 days
given to vote when every one is busy discussing a new property syntax.
Traits is cute, but this was a amazing feature of the PHP language, not
obvious, but it's pretty
On Mon, Jan 28, 2013 at 3:49 PM, Alan Knowles a...@roojs.com wrote:
I was trying to vote against, for what it's worth.
trying to re-open the vote and voting after Gustavo announced that the
voting was closed?
that's sounds a little bit weird.
It's a major bc break with no obvious value,
On 28 January 2013 14:49, Alan Knowles a...@roojs.com wrote:
I was trying to vote against, for what it's worth.
It's a major bc break with no obvious value, and what appears to be 7 days
given to vote when every one is busy discussing a new property syntax.
See other thread by Zeev :)
On
On 30 July 2012 18:31, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
https://wiki.php.net/rfc/incompat_ctx
An RFC for deprecating and removing $this from incompatible context.
Comments are welcome.
Gustavo, my apologies, the ORIGINAL mail did say a little more about it.
-Original Message-
From: Alan Knowles [mailto:a...@roojs.com]
Sent: Monday, January 28, 2013 4:49 PM
To: Gustavo Lopes; PHP Internals; Alan Knowles
Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible
context
I was trying to vote against, for what it's worth.
Ferenc Kovacs wrote:
But this is a core php feature, for anyone who does not use traits We
use this quite a bit, it may not be for purists, but it has worked
perfectly for years. This is getting a bit silly, change for change sake
I've found this to be a huge wtf when you bump into,
Ok, just checked the mailing list (and sorry for top-posting)
July 31st. RFC announced
Jul 31st - 6 or 7 mails at least one very negative, a couple for it.
August 1,3,5,6 - 5 or 6 emails getting a bit off-topic.
Jan 21st - call to vote (single email - no-one replied on list)... - got
15 +1
hi Zeev,
On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
Can you explain why you think it's a major BC break? The RFC suggested that
the BC break would be minimal and that the likelihood a lot of people used
it is very low. If you think
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Monday, January 28, 2013 5:46 PM
To: Zeev Suraski
Cc: Alan Knowles; Gustavo Lopes; PHP Internals
Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from
incompatible
context
hi Zeev,
On Mon, Jan 28,
On Mon, Jan 28, 2013 at 4:32 PM, Lester Caine les...@lsces.co.uk wrote:
Ferenc Kovacs wrote:
But this is a core php feature, for anyone who does not use traits We
use this quite a bit, it may not be for purists, but it has worked
perfectly for years. This is getting a bit silly, change
On Mon, Jan 28, 2013 at 4:47 PM, Zeev Suraski z...@zend.com wrote:
What does it mean then? That implementing this RFC waits for 6.0 or that
it was invalid in the first place?
Both, if the plan is to get that into 5.x.
--
Pierre
@pierrejoye
--
PHP Internals - PHP Runtime Development
On Mon, Jan 28, 2013 at 4:45 PM, Pierre Joye pierre@gmail.com wrote:
hi Zeev,
On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
Can you explain why you think it's a major BC break? The RFC suggested
that
the BC break would be minimal and
On Mon, Jan 28, 2013 at 4:49 PM, Pierre Joye pierre@gmail.com wrote:
On Mon, Jan 28, 2013 at 4:47 PM, Zeev Suraski z...@zend.com wrote:
What does it mean then? That implementing this RFC waits for 6.0 or that
it was invalid in the first place?
Both, if the plan is to get that into 5.x.
On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye pierre@gmail.com
wrote:
On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
Can you explain why you think it's a major BC break? The RFC suggested
that the BC break would be minimal and that
hi,
On Mon, Jan 28, 2013 at 4:56 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye pierre@gmail.com
wrote:
On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
Can you explain why you think it's a
On Mon, Jan 28, 2013 at 4:59 PM, Pierre Joye pierre@gmail.com wrote:
hi,
On Mon, Jan 28, 2013 at 4:56 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye pierre@gmail.com
wrote:
On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski z...@zend.com
Ferenc Kovacs wrote:
Please Lester, could you stop pretending that E_STRICT errors will crash your
application and kill all the kittens?
There are a bunch of people (myself included) who tries to write E_STRICT free
code so that our application is fast and bugfree?
Yes, there are people who
I also disagree with an open-ended voting period. I'm fine with having
a long voting window, but when a vote is called it should declare when
the voting will end. This just makes sense to me.
Since we're on the topic of voting, I also want to bring up that 50% +
1 is actually pretty low for
On Mon, Jan 28, 2013 at 5:37 PM, Lester Caine les...@lsces.co.uk wrote:
Ferenc Kovacs wrote:
Please Lester, could you stop pretending that E_STRICT errors will crash
your
application and kill all the kittens?
There are a bunch of people (myself included) who tries to write E_STRICT
free
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Monday, January 28, 2013 3:15 PM
To: Peter Cowburn
Cc: Zeev Suraski; Pierre Joye; PHP internals
Subject: Re: [PHP-DEV] Voting periods
On 1/28/2013 6:12 AM, Peter Cowburn wrote:
On 28 January 2013 12:03,
On Jan 28, 2013 6:07 PM, Zeev Suraski
The community that participates in internals isn't necessarily
representative of the community at large.
Letzten me clarify my view. I do not attend hyped conferences, because I
want to meet are not there. However I meet a lot of our silent community,
I agree, but we’re in opposite camps on this feature. What does that mean?
J
I think many of us are purely and simply totally out of sync with our
users. I have no immediate solution but this is something we must solve,
now.
On Jan 28, 2013 6:22 PM, Zeev Suraski z...@zend.com wrote:
I agree, but we’re in opposite camps on this feature. What does that
mean? J
Go back to our roots? :-)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.01.2013 18:35, schrieb Pierre Joye:
On Jan 28, 2013 6:22 PM, Zeev Suraski z...@zend.com wrote:
I agree, but we’re in opposite camps on this feature. What does
that
mean? J
Go back to our roots? :-)
Classless, Exception-less and when
Zeev Suraski wrote:
They speak in volumes
- PHP 5.4 is used in less than 1% of the sites using PHP today, and even
the relatively revolutionary 5.3 is still a lot less popular than 5.2.
The new shiny features are not all that interesting for most people.
And I wonder how many of the 1% using
just testing my recent change in the accept/reject emails, please first accept
this account then delete it.
thanks.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Approved tyraeltest10 \o/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nuked tyraeltest10
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester,
On Mon, Jan 28, 2013 at 5:37 PM, Lester Caine les...@lsces.co.uk wrote:
I'm not going to go back and list the problems. E_STRICT errors DO cause
problems running legacy code. I've had plenty of white screens until
E_STRICT was switched back off in PHP5.4! Things that are just warnings
Hi!
Zeev, for one, was one of them asking to have a 2/3 majority for any
language related RFC. That's what applies to this RFC, and it is, as
of now, accepted. I don't see how the vote is remotely close to a tie.
I'm sorry, I am seeing 34/21 result. It's 61% for, 39% against - which
means, it
2013/1/28 Zeev Suraski z...@zend.com
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Monday, January 28, 2013 3:15 PM
To: Peter Cowburn
Cc: Zeev Suraski; Pierre Joye; PHP internals
Subject: Re: [PHP-DEV] Voting periods
On 1/28/2013 6:12 AM, Peter
2012.04.20. 8:08, Stas Malyshev smalys...@sugarcrm.com ezt írta:
Hi!
I can't estimate the amount of breakage, but what about using underscore
(literal _) without quotation marks?
This one is taken. See: http://us2.php.net/_
--
Stanislav Malyshev, Software Architect
SugarCRM:
Hey all,
After reading the Voting Periods email thread, I'm left wondering a simple
question (which has a difficult answer):
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?
I've always approached it as we're voting for the concept (and
Hi!
I mean more no matter if it is or not, but the result is not tie
anyway, accepted or not.
Remember we talked about this while discussing voting? What we have here
is a huge language feature (and, like it or dislike it, it is a big
feature which had a lot of effort, energy and though spent
On Jan 28, 2013, at 2:14 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
After reading the Voting Periods email thread, I'm left wondering a simple
question (which has a difficult answer):
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the
In the past months, I talked to a lot of German companies using PHP or Java:
All PHP companies were using 5.2/5.3 and planned to upgrade to 5.4.
Almost all were using default binaries from their favorite Linux
distribution on their production systems.
Only one was building their own extensions,
Hi!
what is the status of the rfc?
were there any reasons why you didn't called for votes?
Personally I would prefer named parameters also, and I think that we are
too close to the 5.5 feature freeze, but somebody asked why did the
progress stopped and I don't think that there were any
Re: https://github.com/nikic/scalar_objects
Initial impression: This patch reminds me of extending native prototypes in Javascript,
with similar limitations that may explain why this has fallen out of fashion in JS. The
big one is that allowing change to the prototypes introduces global state
Hi!
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?
Either, or both, depending on the RFC and the intent of the author. Note
that since there's rarely competing teams/patches on the same feature,
accepting the RFC means also accepting the
Stas,
Remember we talked about this while discussing voting? What we have here
is a huge language feature (and, like it or dislike it, it is a big
feature which had a lot of effort, energy and though spent on it, and
also has a lot of consequences for PHP language, which may be good or
bad
hi,
On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
After reading the Voting Periods email thread, I'm left wondering a simple
question (which has a difficult answer):
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on
Hi!
If we introduced BC breaks other than those, then we'd to review them
and see why they have been introduced. But one thing is clear: we do
not allow BC breaks between 5.x and 5.x+1.
We need a better definition of BC break then. Is deprecating an existing
feature BC break? Is adding a
Can we stop calling things new shiny features as if that means
anything? It's
empty rhetoric. When you treat your users like unintelligent noobies who
are
just going to hang themselves when you give them a rope, then that's the
type
of users you will end up with.
If it doesn't mean anything,
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?
I think it should be exclusively on the concept. We never vote about code
changes anywhere - including when we refactor existing parts. Why would
we vote about the implementation here?
The
Hi!
I've started a vote on CURLFile RFC:
https://wiki.php.net/rfc/curl-file-upload#vote
Please vote.
Looks like the feature has been approved almost anonymously, so I'll be
proceeding with merging the pull soon. I'm also planning adding __wakeup
there that blocks unserializing CURLFile, for
On Mon, Jan 28, 2013 at 12:53 PM, Zeev Suraski z...@zend.com wrote:
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?
I think it should be exclusively on the concept. We never vote about code
changes anywhere - including when we refactor
To Zeev and the rest of internals,
I know this will be a long e-mail but I'm not a guy who goes to conferences
(I don't have money for that), I've been into seven companies until now,
each with various use cases for PHP and I'm trying to contribute to some
open source projects from PHP scene.
Zeev Suraski wrote:
PHP has become the most popular Web language in existence WITHOUT these
features. Most users couldn't care less about them. They're happy
without them. They're happ*ier* without them. They'd rather a faster PHP
that did exactly the same thing it does today - and not a
On Jan 28, 2013 8:41 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
If we introduced BC breaks other than those, then we'd to review them
and see why they have been introduced. But one thing is clear: we do
not allow BC breaks between 5.x and 5.x+1.
We need a better definition of
-Original Message-
From: Levi Morrison [mailto:morrison.l...@gmail.com]
Sent: Monday, January 28, 2013 10:04 PM
To: Zeev Suraski
Cc: Anthony Ferrara; internals@lists.php.net
Subject: Re: [PHP-DEV] Purpose of voting
On Mon, Jan 28, 2013 at 12:53 PM, Zeev Suraski z...@zend.com wrote:
Hi!
Looks like the feature has been approved almost anonymously, so I'll be
Unanimously of course :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Hey all,
After reading the Voting Periods email thread, I'm left wondering a simple
question (which has a difficult answer):
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the
On Mon, 28 Jan 2013, Anthony Ferrara wrote:
I've always approached it as we're voting for the concept (and details)
provided in the RFC. But it appears that other people have been voting on
the specifics of the attached patch (so theoretically an RFC could be
rejected entirely because some
2013/1/28 Zeev Suraski z...@zend.com:
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?
I think it should be exclusively on the concept. We never vote about code
changes anywhere - including when we refactor existing parts. Why would
we
2013/1/28 Derick Rethans der...@php.net:
Both the idea and implementation needs to be sound. If not, I vote no
(and that also means no when it makes APC's life harder).
This is a bit unfair. APC is just one byte code caching mechanism out
there, even if it's the mostly used or most performing
On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT patrickalla...@php.netwrote:
2013/1/28 Zeev Suraski z...@zend.com:
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?
I think it should be exclusively on the concept. We never vote
On Mon, Jan 28, 2013 at 10:24 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT patrickalla...@php.net
wrote:
It's perfectly valid to accept an RFC and comment on the
implementation on what should be improved or what sucks in it.
If one is
Zeev Suraski in php.internals (Mon, 28 Jan 2013 21:50:14 +0200):
PHP has become the most popular Web language in existence WITHOUT these
features. Most users couldn't care less about them. They're happy
without them. They're happ*ier* without them. They'd rather a faster PHP
that did exactly
Zeev Suraski wrote:
The vast majority of the PHP community is a silent one; These people
don't participate here on internals; They don't attend conferences; They
use it - the vast majority of them in a professional manner - and they
picked it because they like it the way it is, not because
On Monday, January 28, 2013 11:30 PM, Zeev Suraski wrote:
Alan,
Can you explain why you think it's a major BC break? The RFC suggested that
the BC break would be minimal and that the likelihood a lot of people used
it is very low. If you think differently and share it it might put it in a
hi Jan,
On Tue, Jan 29, 2013 at 3:50 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
De spijker op z'n kop, as the saying over here in Amsterdam is. There
are two reasons why I try to change to PHP 5.4 once in a while:
1. In my testing it is a little bit (10%) faster than PHP 5.3.
2. PHP 5.3 will
Hi!
ago I was once again confronted with errors under PHP 5.4. The module,
responsible for the error: Content Access.
http://drupal.org/node/1533186
I see there: Notice: Array to string conversion in
form_process_checkbox(). This means the module has a bug, and pretty bad
one at that,
Hi!
I've used this in other places, it's basically lightweight traits, and
has always been perfectly valid code. There does not seem to be a clear
justification for deprecating it other than, It's not the way 'some'
people like code to work...
Well, I think the reason is that this code is
On 01/28/2013 08:54 PM, Ryan McCue wrote:
Zeev Suraski wrote:
The vast majority of the PHP community is a silent one; These people
don't participate here on internals; They don't attend conferences; They
use it - the vast majority of them in a professional manner - and they
picked it because
Larry Garfield wrote:
Hi Ryan. While I understand that level of conservatism, I think it is
somewhat unfounded. The PHP community at large decided to deprecate PHP
4 en masse, and put hosts on notice. It worked, too. The GoPHP5 project
included over 100 projects and 200 hosts that
On 01/29/2013 01:30 AM, Ryan McCue wrote:
If Wordpress announced that it was going to start requiring PHP 5.3 as
of some date 6+ months in the future (and there are advantages to doing
so that don't require major BC breaking rewrites), I think you'd see a
rather significant abandonment of PHP
Larry Garfield wrote:
It's great to hear you say that, given that the messaging coming out of
WP at the time was rather hostile. :-)
As I noted, the dynamics have changed significantly. I'd say that core
committer team as a whole is now much less conservative than before,
although they're still
93 matches
Mail list logo
