Re: [PHP-DEV] RFC ? gethostbyname - getnameinfo()
Not sure, I tried something locally and this is what i came up with (and what i think expected behaviour could be) wrote: > 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 : > >> 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 in php is deprecated, and that getnameinfo should be used. >> >> I think that in an age where we are finally getting the support of the *big* >> boys to start using IPv6 that php should be there and ready for them. >> >> I have never contributed to php core before, but i'm more than happy to take >> the lead on this one. >> >> Please let me know what you guys think, and thank you for your time. >> >> Kind regards, >> Sam Hermans >> >> >> -- >> 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
Re: [PHP-DEV] Re: libmagic 5.14 upgrade
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 5.3/4 later. I consider it a feature and not a necessary bugfix. In addition anatoly is saying that there are still problems with the patch. Both are reasons for me to believe that upgrading it 1-1.5 month before a final is not worth the risk. I would prefer to be more strict about the "feature freeze" than we were with 5.3 and 5.4. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
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: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: libmagic 5.14 upgrade
On Wed, Mar 27, 2013 at 7:29 PM, David Soria Parra 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 even as dev >> - older/custom magic files might be incompatible >> >> pro: >> - latest libmagic data >> - better safety for the future >> - in a year all that libs are for sure upgraded in the main distros >> - further upgrades can be better handled > > HI Anatol, > > thanks for putting this patch together. However as we already reached > feature freeze and we are will have beta2 tomorrow I think it's a bit > too late for so much new code. I cannot really judge the sideeffects of > this upgrade and would prefer to be strict about the feature freeze. So > please do not update the library unless Stas decides that he wants to do > it in 5.4, in that case I have to go with his decision. 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 5.3/4 later. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 and clang
On Tue, Mar 26, 2013 at 3:55 PM, Ondřej Surý 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 (a Clang static analysis tool). Would you be interested? > > It does seem to produce lot of fatal errors on lot of places, so it seems > that php5 can be used to improve llvm/clang as well :). > > O. > -- > Ondřej Surý > for the record, Sebastian did this for 5.4, maybe it would be interesting to you: http://sebastian-bergmann.de/archives/916-Using-CLANGscan-build-for-Static-Analysis-of-the-PHP-Interpreter.html see http://marc.info/?l=php-internals&m=132847183930339&w=1 for the discussion about the results -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: PHP 5.5 and clang
On 2013-03-26, Ond?ej Sur? 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 one shot only. > Hi Ondrey, yes I would be very interested in these results. I personally build PHP with clang most of the time and think we should use it's features to provide better analytics. Also I think since freebsd switched to clang ,we should ensure that PHP can be compiled with clang. Thank you very much for your work, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: libmagic 5.14 upgrade
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: > - latest libmagic data > - better safety for the future > - in a year all that libs are for sure upgraded in the main distros > - further upgrades can be better handled HI Anatol, thanks for putting this patch together. However as we already reached feature freeze and we are will have beta2 tomorrow I think it's a bit too late for so much new code. I cannot really judge the sideeffects of this upgrade and would prefer to be strict about the feature freeze. So please do not update the library unless Stas decides that he wants to do it in 5.4, in that case I have to go with his decision. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
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
Re: [PHP-DEV] RFC ? gethostbyname - getnameinfo()
On Wed, Mar 27, 2013 at 1:39 PM, Sam Hermans 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 gethostbyname prefers IPv4. It seems that the gethostbyname > function as used in php is deprecated, and that getnameinfo should be > used. > > I think that in an age where we are finally getting the support of the > *big* boys to start using IPv6 that php should be there and ready for them. > > I have never contributed to php core before, but i'm more than happy to > take the lead on this one. > > Please let me know what you guys think, and thank you for your time. > > Kind regards, > Sam Hermans > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > you mean REMOTE_ADDR? what SAPI are you using? AFAIK REMOTE_ADDR (as most other $_SERVER variables) is coming from the webserver itself: http://lxr.php.net/xref/PHP_5_5/sapi/apache/mod_php5.c#254 http://lxr.php.net/search?q=REMOTE_ADDR&defs=&refs=&path=&hist=&project=PHP_5_5 I suppose it will contain whatever address your server received the request (be that an ipv4 or ipv6 address). on the other hand gethostbyname by definition returns an IPV4 address for the given host. this is the intended and documented behavior. there is an open feature request (with a patch) for changing that behavior to return IPv6 address: https://bugs.php.net/bug.php?id=49493&edit=1 personally I think that we should introduce this feature without breaking any BC, so a new function or a new optional argument should be added. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] DateTimeImmutable
On Wed, Mar 27, 2013 at 2:14 PM, Pierre Joye wrote: > On Wed, Mar 27, 2013 at 1:49 PM, Andreas Heigl 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 subset of DateTime public methods, including > >> only the readonly ones. > >> > >> I can't imagine how this could possibly be named in a sane way though :/ > > > > DateTimeInterface or DateTimeROInterface? > > > I'd to re post Lars suggestion from another thread. Do a RFC. This is > going again in all possible directions and I fear that we will not get > a good solution at the end of the day. > > Cheers, > -- > Pierre > > @pierrejoye > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > agree, but the current implementation shouldn't be shipped until we find an acceptable solution. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] DateTimeImmutable
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 potentially broken. The code may and should be able to expect a modifiable instance of DateTime, which is no longer guaranteed. ... In my opinion, the only way to "solve" this issue is through documentation, advocation, publication and providing DateTimeImmutable as a sibling to DateTime. Much agreed. DateTimeImmutable is welcomed as a better design, but it is not a clean substitute for a DataTime object. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC ? gethostbyname - getnameinfo()
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 : > 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 in php is deprecated, and that getnameinfo should be used. > > I think that in an age where we are finally getting the support of the *big* > boys to start using IPv6 that php should be there and ready for them. > > I have never contributed to php core before, but i'm more than happy to take > the lead on this one. > > Please let me know what you guys think, and thank you for your time. > > Kind regards, > Sam Hermans > > > -- > 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
Re: [PHP-DEV] DateTimeImmutable
On Wed, Mar 27, 2013 at 1:49 PM, Andreas Heigl 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 subset of DateTime public methods, including >> only the readonly ones. >> >> I can't imagine how this could possibly be named in a sane way though :/ > > DateTimeInterface or DateTimeROInterface? I'd to re post Lars suggestion from another thread. Do a RFC. This is going again in all possible directions and I fear that we will not get a good solution at the end of the day. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
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 can't imagine how this could possibly be named in a sane way though :/ DateTimeInterface or DateTimeROInterface? Cheers > > Cheers > -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ smime.p7s Description: S/MIME Kryptografische Unterschrift
[PHP-DEV] RFC ? gethostbyname - getnameinfo()
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 in php is deprecated, and that getnameinfo should be used. I think that in an age where we are finally getting the support of the *big* boys to start using IPv6 that php should be there and ready for them. I have never contributed to php core before, but i'm more than happy to take the lead on this one. Please let me know what you guys think, and thank you for your time. Kind regards, Sam Hermans -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
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 a sane way though :/ Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
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 : > 2013.03.26. 20:29, "Michael Wallner" 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 frustration with a DateTime that should not have >> been modifiable in the first place and the wish to improve upon things >> and to lead users to the proper way. But, this is not the right way. >> >> 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 potentially broken. The code may and >> should be able to expect a modifiable instance of DateTime, which is >> no longer guaranteed. >> >> The argument, that it was implemented this way, so that method >> signatures do not have to be changed, is weak, because every method >> has to be reviewed, and a method signature change would actually be >> the right thing to accept a DateTimeImmutable, because it does not act >> like a DateTime. >> >> It will lead to lots of boilerplate typechecking code with instanceof >> because it actually is not the same type. DateTimeImmutable extending >> DateTime will instantly create BC issues, which we will suffer from a >> long time. >> >> The toughtful developer, which already cloned the DateTimes in his >> methods won't benefit either, because now he's cloning >> DateTimeImmutables. >> >> In my opinion, the only way to "solve" this issue is through >> documentation, advocation, publication and providing DateTimeImmutable >> as a sibling to DateTime. >> >> DateTime is here, and we cannot go back in time, but we might >> deprecate DateTime* and introduce a date namespace in PHP-next to >> clean up this front, but this already goes beyond the issue with >> DateTimeImmutable. >> >> >> -- >> Regards, >> Mike >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > would it make sense to introduce an interface wich both DateTime and > DateTimeImmutable implements? > that way you can typehint for both if you know that both classes are fine > for you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
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 assumption that a DateTime value is fixed in > some way? There have been various statements about 'should have been immutable > from the beginning', and while I can see that some uses of it are read only, > much of my own use is in building calendar arrays where one is adding months, > days or hours to select the next set of matches. If this should always have > been 'immutable' then how would one handle all the situations where one does > need to update the value? The updated value is still returned, it's just that the original object you call (f.e.) ->modify() on is not. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
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 some way? There have been various statements about 'should have been immutable from the beginning', and while I can see that some uses of it are read only, much of my own use is in building calendar arrays where one is adding months, days or hours to select the next set of matches. If this should always have been 'immutable' then how would one handle all the situations where one does need to update the value? Now there has been discussions about setters and getters and read only, so surely this is just another example of something were flagging a variable as read only would be useful rather than programming in yet another special case? -- 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 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
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 List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
2013.03.26. 20:29, "Michael Wallner" 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 frustration with a DateTime that should not have > been modifiable in the first place and the wish to improve upon things > and to lead users to the proper way. But, this is not the right way. > > 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 potentially broken. The code may and > should be able to expect a modifiable instance of DateTime, which is > no longer guaranteed. > > The argument, that it was implemented this way, so that method > signatures do not have to be changed, is weak, because every method > has to be reviewed, and a method signature change would actually be > the right thing to accept a DateTimeImmutable, because it does not act > like a DateTime. > > It will lead to lots of boilerplate typechecking code with instanceof > because it actually is not the same type. DateTimeImmutable extending > DateTime will instantly create BC issues, which we will suffer from a > long time. > > The toughtful developer, which already cloned the DateTimes in his > methods won't benefit either, because now he's cloning > DateTimeImmutables. > > In my opinion, the only way to "solve" this issue is through > documentation, advocation, publication and providing DateTimeImmutable > as a sibling to DateTime. > > DateTime is here, and we cannot go back in time, but we might > deprecate DateTime* and introduce a date namespace in PHP-next to > clean up this front, but this already goes beyond the issue with > DateTimeImmutable. > > > -- > Regards, > Mike > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > would it make sense to introduce an interface wich both DateTime and DateTimeImmutable implements? that way you can typehint for both if you know that both classes are fine for you.
