2013.03.26. 20:29, Michael Wallner m...@php.net ezt írta:
Hi all!
I am concerned by the introduction of DateTimeImmutable extending
DateTime, and despite not being the talking guy, I'll try to outline
the reasons why I and obviously a lot of other people think so.
I can understand the
On Wed, 20 Feb 2013, Gustavo Lopes wrote:
The solution is simple: separate the classes and provide a
toDateTime() on DateTimeImmutable for interoperability purposes.
Do you have time to make a patch? I unfortunately don't.
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing
Levi Morrison wrote:
While I personally think DateTime should have been immutable from the
beginning, I don't think it's in PHP's best interest to try to fix
this particular problem by introducing DateTimeImmutable.
There seems to be some strange assumption that a DateTime value is fixed in
On Wed, 27 Mar 2013, Lester Caine wrote:
Levi Morrison wrote:
While I personally think DateTime should have been immutable from the
beginning, I don't think it's in PHP's best interest to try to fix
this particular problem by introducing DateTimeImmutable.
There seems to be some strange
Not really, as an interface guarantees behavior, which is not possible for
DateTimeImmutable and DateTime.
Am 27.03.2013 um 09:03 schrieb Ferenc Kovacs tyr...@gmail.com:
2013.03.26. 20:29, Michael Wallner m...@php.net ezt írta:
Hi all!
I am concerned by the introduction of
On 27.03.2013 13:18, Lars Strojny wrote:
Not really, as an interface guarantees behavior, which is not possible for
DateTimeImmutable and DateTime.
The interface could be a subset of DateTime public methods, including
only the readonly ones.
I can't imagine how this could possibly be named in
Hi,
The rcf howto pushed me into mailing you guys to measure reaction.
For a project i am working on i struggle a lot with the fact that
$_SERVER['REMOTE_ADDRESS'] return policy is to prefer IPv6 over IPv4, and that
gethostbyname prefers IPv4. It seems that the gethostbyname
function as used
Am 27.03.13 13:41, schrieb Jordi Boggiano:
On 27.03.2013 13:18, Lars Strojny wrote:
Not really, as an interface guarantees behavior, which is not possible for
DateTimeImmutable and DateTime.
The interface could be a subset of DateTime public methods, including
only the readonly ones.
I
On Wed, Mar 27, 2013 at 1:49 PM, Andreas Heigl andr...@heigl.org wrote:
Am 27.03.13 13:41, schrieb Jordi Boggiano:
On 27.03.2013 13:18, Lars Strojny wrote:
Not really, as an interface guarantees behavior, which is not possible for
DateTimeImmutable and DateTime.
The interface could be a
I agree, PHP should have world-class support for v6. What is your proposal
exactly?
Am 27.03.2013 um 13:39 schrieb Sam Hermans s...@mujo.be:
Hi,
The rcf howto pushed me into mailing you guys to measure reaction.
For a project i am working on i struggle a lot with the fact that
On 3/26/13 3:29 PM, Michael Wallner wrote:
I am concerned by the introduction of DateTimeImmutable extending
DateTime
...
If interoperability was in mind, it will not be given, because every
single API which has been written in the last seven years and has
DateTime in it's signature is
On Wed, Mar 27, 2013 at 2:14 PM, Pierre Joye pierre@gmail.com wrote:
On Wed, Mar 27, 2013 at 1:49 PM, Andreas Heigl andr...@heigl.org wrote:
Am 27.03.13 13:41, schrieb Jordi Boggiano:
On 27.03.2013 13:18, Lars Strojny wrote:
Not really, as an interface guarantees behavior, which is not
On Wed, Mar 27, 2013 at 1:39 PM, Sam Hermans s...@mujo.be wrote:
Hi,
The rcf howto pushed me into mailing you guys to measure reaction.
For a project i am working on i struggle a lot with the fact that
$_SERVER['REMOTE_ADDRESS'] return policy is to prefer IPv6 over IPv4, and
that
On Wed, 2013-03-27 at 17:10 +0100, Ferenc Kovacs wrote:
agree, but the current implementation shouldn't be shipped until we
find an acceptable solution.
+1
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 03/26/2013 11:44 PM, Anatol Belski wrote:
What +/- I personally see upgrading this at this time:
contra:
- there might be bugs, the next release might have not all them fixed
- 5.11 is what the latest linux exts have even as dev
- older/custom magic files might be incompatible
pro:
-
On 2013-03-26, Ond?ej Sur? ond...@sury.org wrote:
--bcaec548a7f385895a04d8d51fce
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
I am trying to build PHP 5.5beta1 with clang, so the question is:
Would you be interested in the results? This would be
On Tue, Mar 26, 2013 at 3:55 PM, Ondřej Surý ond...@sury.org wrote:
Hi,
I am trying to build PHP 5.5beta1 with clang, so the question is:
Would you be interested in the results? This would be one shot only.
The next step would be to do automatic builds and publishing results of
scan-build
On Wed, Mar 27, 2013 at 7:29 PM, David Soria Parra dso...@gmx.net wrote:
On 03/26/2013 11:44 PM, Anatol Belski wrote:
What +/- I personally see upgrading this at this time:
contra:
- there might be bugs, the next release might have not all them fixed
- 5.11 is what the latest linux exts have
On Tue, 26 Mar 2013, Michael Wallner wrote:
providing DateTimeImmutable as a sibling to DateTime.
That's fine with me, but I am not having the time to work on a patch
right now.
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 03/27/2013 09:35 PM, Pierre Joye wrote:
We have done that many times in the past for 5.3 and 5.4. It is
relatively risk free. Even more for 5.5 during beta phase. It does not
add new features but fixes bugs.
The good side effect is that we can test it well with 5.5 and back
port to
Not sure,
I tried something locally and this is what i came up with (and what i think
expected behaviour could be)
?php
echo IPv6 preferred host (no A record, but CNAME to A):\n;
var_dump(gethostbyname(ipv6.google.com));
echo \nIPv4 preferred host with records: \n;
21 matches
Mail list logo
