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 stil
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 5.2
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 collec
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
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
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, array
hi Jan,
On Tue, Jan 29, 2013 at 3:50 AM, Jan Ehrhardt 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 be out of supp
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
dif
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 becau
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 exactl
On Mon, Jan 28, 2013 at 10:24 PM, Ferenc Kovacs wrote:
> On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT >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 voting "no" mostly because of the i
On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT wrote:
> 2013/1/28 Zeev Suraski :
> >> 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 any
2013/1/28 Derick Rethans :
> 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 one (and e
2013/1/28 Zeev Suraski :
>> 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
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
On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara 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 patch itself?
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: http://www.p
> -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 wrote:
> >>
On Jan 28, 2013 8:41 PM, "Stas Malyshev" 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 BC break th
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 slow
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.
You
On Mon, Jan 28, 2013 at 12:53 PM, Zeev Suraski 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 existin
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,
> 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?
Th
> 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 anyth
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 no
hi,
On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara 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 patch it
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!
> 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 th
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 w
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 s
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, bas
On Jan 28, 2013, at 2:14 PM, Anthony Ferrara 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 patch itself?
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 spe
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 deta
2012.04.20. 8:08, "Stas Malyshev" 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: http://www.sugarc
2013/1/28 Zeev Suraski
> > -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, P
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,
Lester,
On Mon, Jan 28, 2013 at 5:37 PM, Lester Caine 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 in
> PHP5.3.
T
Nuked tyraeltest10
--
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
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
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 5.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.01.2013 18:35, schrieb Pierre Joye:
> On Jan 28, 2013 6:22 PM, "Zeev Suraski" 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 som
On Jan 28, 2013 6:22 PM, "Zeev Suraski" wrote:
>
> I agree, but we’re in opposite camps on this feature. What does that
mean? J
Go back to our roots? :-)
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: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
> -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
On Mon, Jan 28, 2013 at 5:37 PM, Lester Caine 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
>> cod
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 someth
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 igno
On Mon, Jan 28, 2013 at 4:59 PM, Pierre Joye wrote:
> hi,
>
> On Mon, Jan 28, 2013 at 4:56 PM, Gustavo Lopes wrote:
>> On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye
>> wrote:
>>
>>> On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski wrote:
>
> -Original Message-
>>>
>>>
Can yo
hi,
On Mon, Jan 28, 2013 at 4:56 PM, Gustavo Lopes wrote:
> On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye
> wrote:
>
>> On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski wrote:
-Original Message-
>>
>>
>>> Can you explain why you think it's a major BC break? The RFC suggested
>
On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye
wrote:
On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski 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 use
On Mon, Jan 28, 2013 at 4:49 PM, Pierre Joye wrote:
> On Mon, Jan 28, 2013 at 4:47 PM, Zeev Suraski 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.
Let me clarify, in my pre
On Mon, Jan 28, 2013 at 4:45 PM, Pierre Joye wrote:
> hi Zeev,
>
> On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski 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
On Mon, Jan 28, 2013 at 4:47 PM, Zeev Suraski 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 Mailing List
To un
On Mon, Jan 28, 2013 at 4:32 PM, Lester Caine 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 for cha
> -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,
hi Zeev,
On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski 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 differently and
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 vot
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,
> -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
On 30 July 2012 18:31, Gustavo Lopes 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.
On 28 January 2013 14:49, Alan Knowles 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 20 January
On Mon, Jan 28, 2013 at 3:49 PM, Alan Knowles 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, and what appe
On Mon, 28 Jan 2013 15:49:26 +0100, Alan Knowles 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.
Traits is cute, but this was a amaz
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 s
On Mon, Jan 28, 2013 at 3:17 PM, Alan Knowles 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've rest
On Mon, 28 Jan 2013 15:17:21 +0100, Alan Knowles 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 were trying to do,
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 is
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
On Sun, 20 Jan 2013 20:17:05 +0100, Gustavo Lopes
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 for 5.5 (change E_STRI
> +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 nikit
On 1/28/2013 6:12 AM, Peter Cowburn wrote:
On 28 January 2013 12:03, Clint Priest 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 voting period" and
> 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
On Mon, Jan 28, 2013 at 2:00 PM, Zeev Suraski 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 abo
> -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
> 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 ar
hi Clint, Zeev,
On Mon, Jan 28, 2013 at 1:03 PM, Clint Priest 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 particula
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
On 28 January 2013 12:03, Clint Priest 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 unsubscribe, visit: http:
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 (https://github.com/n
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 i
On Mon, Jan 28, 2013 at 12:19 PM, Zeev Suraski 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 billions o
> -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 wrote:
> >> > My suggestion is for votin
hi,
On Mon, Jan 28, 2013 at 11:57 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.
>>
>> You were one of the person w
> > 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
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 w
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 va
hi,
On Mon, Jan 28, 2013 at 10:22 AM, Zeev Suraski 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 a
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,
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 t
> 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 wo
94 matches
Mail list logo
