Hi,
after 5.4.0 was released we had a discussion on 5.3 EOL. Even though it
wasn't properly documented the overall consensus was to go with option
one from https://wiki.php.net/rfc/php53eol "One year with bugs fixes
followed by one year with security fixes only"
So as quick reminder and help for
Le 06/12/2012 22:34, David Soria Parra a écrit :
> On 2012-12-06, Sebastian Bergmann wrote:
>> I brought this up on #php.pecl yesterday and David already investigated
>> a bit but I thought I should probably bring this up here as well.
>>
>> I cannot build PHP-5.5 with --enable-dtrace on Fedora
Hi internals,
what do you think about improving the modification functionality of the
DateTime class. I always get a cold shiver, when I write something like this:
modify(‘+15 day’);
In my opinion it would be nicer if one could write:
$date->modify(15, DateTime::INTERVAL_DAY); // for adding 15 d
Heya,
To me, an interval is well represented by DateInterval, while the
DateTime::modify() method looks more like a shortcut to it. Do you really
need the additional functionality? Shouldn't it be easier to $date->add(new
DateInterval('P15D')); ? It is also a better representation of an interval
t
On 10 December 2012 18:58, Johannes Schlüter wrote:
> As of this date the 5.3 branch will go to extended support and should
> receive security fixes only. Releases will be made based on need.
>
> Please mind that the above schedule is tentative and unpredictable
> events might change this.
>
> Com
On Mon, 10 Dec 2012 16:09:36 +0400, Christian Stoller
wrote:
Hi internals,
what do you think about improving the modification functionality of the
DateTime class. I always get a cold shiver, when I write something like
this:
modify(‘+15 day’);
In my opinion it would be nicer if one cou
Hi,
are you mabe just looking for
$date->add(new DateInterval('P15D'));
?
2012/12/10 Christian Stoller
> Hi internals,
>
> what do you think about improving the modification functionality of the
> DateTime class. I always get a cold shiver, when I write something like
> this:
> $date = new
Hm... I know '$date->add(new DateInterval('P15D'));' is possible, but it has
the same problem.
I have to write:
$date = new DateTime()
$date->add(new DateInterval('P' . getDaysToAddMethod() . 'D'));
I think it is very hard to read. Or is it just my personal point of view?
@Nikita: I know what
It's just a matter of getting used to it IMO. I am not sure if you can
simply modify its public properties, but if that's the case, that should
handle your problem.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
Hello all,
On a pull request submitted via github, it was suggested to me that I
should write an RFC about the feature that I'm proposing as well as to
write about it here on the internals mail list.
However, creating new pages (including RFCs) on wiki.php.net doesn't
seem to be allowed for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 10.12.2012 13:21, schrieb Adam Harvey:
> RHEL 6, Debian 6, Ubuntu 12.04 (not the latest stable version,
> unlike the others, but the LTS version), Mac OS X 10.8 (and many of
> the derivatives of these distros, particularly RHEL) are all
> shipping
Hi,
On Mon, 2012-12-10 at 20:21 +0800, Adam Harvey wrote:
> At the very least, I think we should keep full support going until
> 5.5.0 final is out, which it strikes me probably won't be in February
> at our current rate.
>
> Beyond that, I don't particularly want to create a rod for our own
> ba
On 10 December 2012 20:51, Johannes Schlüter wrote:
> Hi,
>
> On Mon, 2012-12-10 at 20:21 +0800, Adam Harvey wrote:
>> I'm not suggesting we necessarily extend full support, but I wonder if
>> one year of critical bug fixes and security updates will be enough.
>
> In my opinion key for this is PR.
hi Johannes,
On Mon, Dec 10, 2012 at 11:58 AM, Johannes Schlüter wrote:
> Hi,
>
> after 5.4.0 was released we had a discussion on 5.3 EOL. Even though it
> wasn't properly documented the overall consensus was to go with option
> one from https://wiki.php.net/rfc/php53eol "One year with bugs fix
I agree with Christian in the sense that the readability gets compromised.
But I also think that a custom DateTime class should solve the problem
properly, since readability is not a general requirement.
My solution for that problem would be to create that extension and have
those nice methods on
On Mon, Dec 10, 2012 at 1:28 PM, Andrey Andreev wrote:
> Hello all,
> On a pull request submitted via github, it was suggested to me that I
> should write an RFC about the feature that I'm proposing as well as to
> write about it here on the internals mail list.
> However, creating new pages (inc
On Mon, 2012-12-10 at 21:08 +0800, Adam Harvey wrote:
> To be honest, Debian isn't really the distribution I'm worried about.
> Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles
> off, it seems.
>
> RHEL and Ubuntu are mostly the ones I'm thinking of here — RHEL 7 is
> supposed
Hi,
On Mon, 2012-12-10 at 14:10 +0100, Pierre Joye wrote:
> There was no consensus, I am not sure where you get the idea.
By spending the time to go through the thread, taking the opinions
stated there, filtering out side discussions (like LTS based release
models etc) evaluating it (partly subje
So there had been at least two or three messages (subjects) about DateTime
object and everytime there was this problem - people tend to take DateTime
object as mutable object and it really is.
As long as we know, it's not so good - date is immutable by nature. I
don't want to write here why i
On 10/12/12 16:18, Nikita Nefedov wrote:
> So there had been at least two or three messages (subjects) about
> DateTime object and everytime there was this problem - people tend to
> take DateTime object as mutable object and it really is.
> As long as we know, it's not so good - date is immutable
On 10/12/12 13:35, Christian Stoller wrote:
> Hm... I know '$date->add(new DateInterval('P15D'));' is possible, but it has
> the same problem.
>
> I have to write:
>
> $date = new DateTime()
> $date->add(new DateInterval('P' . getDaysToAddMethod() . 'D'));
>
> I think it is very hard to read. Or i
On Mon, Dec 10, 2012 at 11:39 AM, Ángel González wrote:
> On 10/12/12 16:18, Nikita Nefedov wrote:
>> So there had been at least two or three messages (subjects) about
>> DateTime object and everytime there was this problem - people tend to
>> take DateTime object as mutable object and it really i
On 10.12.2012 15:24, Johannes Schlüter wrote:
> On Mon, 2012-12-10 at 21:08 +0800, Adam Harvey wrote:
>> To be honest, Debian isn't really the distribution I'm worried about.
>> Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles
>> off, it seems.
>>
>> RHEL and Ubuntu are mostly t
Has APC's PHP 5.4.x support matured yet to the point where folks are
comfortable there's no environment in which you really shouldn't run
5.3?
On Mon, Dec 10, 2012 at 3:10 PM, Florian Anderiasch
wrote:
> On 10.12.2012 15:24, Johannes Schlüter wrote:
>> On Mon, 2012-12-10 at 21:08 +0800, Adam Harv
(Really shouldn't run 5.4, rather)
On Mon, Dec 10, 2012 at 3:52 PM, Tom Boutell wrote:
> Has APC's PHP 5.4.x support matured yet to the point where folks are
> comfortable there's no environment in which you really shouldn't run
> 5.3?
>
> On Mon, Dec 10, 2012 at 3:10 PM, Florian Anderiasch
> wr
hi,
On Mon, Dec 10, 2012 at 9:52 PM, Tom Boutell wrote:
> Has APC's PHP 5.4.x support matured yet to the point where folks are
> comfortable there's no environment in which you really shouldn't run
> 5.3?
For most apps it should work fine now. There are one or two issues in
some edge cases but w
Sure. I wasn't asking for myself but rather in the context of how
close 5.3 is to being reasonable to deprecate.
On Mon, Dec 10, 2012 at 3:55 PM, Pierre Joye wrote:
> hi,
>
> On Mon, Dec 10, 2012 at 9:52 PM, Tom Boutell wrote:
>> Has APC's PHP 5.4.x support matured yet to the point where folks a
On 12/10/2012 12:59 PM, Tom Boutell wrote:
> Sure. I wasn't asking for myself but rather in the context of how
> close 5.3 is to being reasonable to deprecate.
APC is at the point now for 5.4 where I don't think there are any more
edge cases than we have in 5.3. Neither is perfect, but it is close
On 11/12/12 06:59, Herman Radtke wrote:
On Mon, Dec 10, 2012 at 11:39 AM, Ángel González wrote:
On 10/12/12 16:18, Nikita Nefedov wrote:
So there had been at least two or three messages (subjects) about
DateTime object and everytime there was this problem - people tend to
take DateTime object
2012/12/10 Adam Harvey :
> On 10 December 2012 18:58, Johannes Schlüter wrote:
>> As of this date the 5.3 branch will go to extended support and should
>> receive security fixes only. Releases will be made based on need.
>>
>> Please mind that the above schedule is tentative and unpredictable
>> e
On Tue, 2012-12-11 at 08:55 +0900, Yasuo Ohgaki wrote:
> 2012/12/10 Adam Harvey :
> > On 10 December 2012 18:58, Johannes Schlüter wrote:
> >> As of this date the 5.3 branch will go to extended support and should
> >> receive security fixes only. Releases will be made based on need.
> >>
> >> Plea
Hi!
> what do you think about improving the modification functionality of the
> DateTime class. I always get a cold shiver, when I write something like this:
> $date = new DateTime()
> $date->modify(‘+15 day’);
>
> In my opinion it would be nicer if one could write:
> $date->modify(15, DateTime
Hi!
> As long as we know, it's not so good - date is immutable by nature. I
> don't want to write here why it's so, I will just throw this link:
> http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html
Date is immutable, but there's no reason why date object should be able
to re
On Mon, 10 Dec 2012, Herman Radtke wrote:
> On Mon, Dec 10, 2012 at 11:39 AM, Ángel González wrote:
> > On 10/12/12 16:18, Nikita Nefedov wrote:
> >> So there had been at least two or three messages (subjects) about
> >> DateTime object and everytime there was this problem - people tend to
> >> t
34 matches
Mail list logo
