Re: [PHP-DEV] Callable typehint

On 28 May 2013 07:00, Ferenc Kovacs wrote: > > > sorry for resurrecting the thread, but I think that having a Callable > typehint would be nice, and I agree with Etienne that the generic arguments > against typehints doesn't really apply here. > We've had "callable" since 5.4.0. > > -- > Fere

Re: [PHP-DEV] DateTime fixes and 5.4 release plan

On Thu, Dec 29, 2011 at 11:51 PM, Daniel Convissor < dani...@analysisandsolutions.com> wrote: > Hi Folks: > > David mentioned the following in the git migration email: > > >Expect the php-src migration in 14-21 days after 5.4 final. > > Can 5.4 final please be held off until the DateTime fixes

[PHP-DEV] Re: supporting the final keyword for properties

On Mon, Jul 16, 2012 at 2:25 PM, Ferenc Kovacs wrote: > Hi, > > The recent > http://www.mail-archive.com/internals@lists.php.net/msg59301.html discussion > made me wonder why did we decide not supporting the final keywords for > properties as it would provide an easy way for read-only attributes

Re: [PHP-DEV] considering to remove ext/imap from master

On Sat, Apr 28, 2012 at 11:31 AM, Pierre Joye wrote: > hi, > > On Sat, Apr 28, 2012 at 3:15 AM, Stas Malyshev > wrote: > > Hi! > > > >> May I ask why you agreed to move sqlite away? That is a very close > >> situation (well, better as sqlite library status was way better than > >> current c-clie

Re: [PHP-DEV] Callable typehint

On Tue, Jun 7, 2011 at 8:50 PM, Stas Malyshev wrote: > Hi! > > > Am I now supposed to create a new thread with [RFC] in the subject, >> wait for minimum 2 weeks, and then create a poll somewhere on the wiki >> and create new thread with [VOTE] in subject, and wait for another >> 2weeks and then i

Re: [PHP-DEV] Proposal for better UTF-8 handling

Hi! > I did mean would — one issue with much of our internationalisation > code is that it's in extensions (intl, iconv, mbstring) that are > inconsistently deployed by shared hosting providers. Having some basic Shared hosting providers are completely capable of building their PHP offerings the

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On Mon, May 27, 2013 at 4:35 PM, Daniel Lowrey wrote: > I understand that you can use php -d, but this is not a portable solution. > My specific use case is running a libevent-based HTTP server and I cannot > even run unit test suites without an .ini file because of this warning. Why > does PHP f

[PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

I understand that you can use php -d, but this is not a portable solution. My specific use case is running a libevent-based HTTP server and I cannot even run unit test suites without an .ini file because of this warning. Why does PHP force me to include configuration directives that it clearly does

Re: [PHP-DEV] Re: date.timezone E_WARNING -- Really necessary? What's the rationale?

On Tue, May 28, 2013 at 12:57 AM, Daniel Lowrey wrote: > > My problem with the current behavior is that it essentially *forces* > the use of an .ini file by triggering an error if no default is > assigned. No it does not. You can use: - php -d ... - date_default_timezone_set > Now, as far as I

[PHP-DEV] Re: date.timezone E_WARNING -- Really necessary? What's the rationale?

Having started this thread I'd like to focus the discussion so we can actually get somewhere. Otherwise opinions will keep streaming in ad nauseum without any real progress. At issue here is not whether UTC makes sense as a default. The question is also not how we can automate the install process

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On 27 May 2013 09:35, Jannik Zschiesche wrote: > Hello, > > > would it be hard to just show the notice as soon as the user actually uses > a function regarding to date/time (and not before)? > > Currently the message is shown all the time, at the start of the script - > even if the script is as s

[PHP-DEV] Removing from git history

>From: Pierre Schmitz >To: internals@lists.php.net >Cc: >Date: Sat, 25 May 2013 05:48:07 +0200 >Subject: Re: [PHP-DEV] Re: About fileinfo test.mp3 >Am 24.05.2013 23:38, schrieb Anatol Belski: >> Hi David, >> >> On Fri, 2013-05-24 at 23:28 +0200, David Soria Parra wrote: >>> Hi Anatol, >>> >>> I sa

[PHP-DEV] Git down for a bit

Sorry folks, in an attempt to address the China mystery(*), I managed to kill y3 which hosts both git and www. I have pointed www to a different server, but we obviously can't do the same with Git. Work locally for now and it should be back soon. It is a holiday in the US so response time from our

Re: [PHP-DEV] Proposal for better UTF-8 handling

hi Adam! On Mon, May 27, 2013 at 6:39 PM, Adam Harvey wrote: > On 26 May 2013 21:05, Stas Malyshev wrote: >> >>> I agree with Nikita — I'm not against adding more Unicode/charset >>> handling functions if they make sense (and I haven't looked at the >>> code for this particular proposal yet), pa

Re: [PHP-DEV] Proposal for better UTF-8 handling

On 26 May 2013 21:05, Stas Malyshev wrote: > >> I agree with Nikita — I'm not against adding more Unicode/charset >> handling functions if they make sense (and I haven't looked at the >> code for this particular proposal yet), particularly if they'd be part >> of a default build, but enough water

Re: [PHP-DEV] Maintaining Phar

+1 On Mon, May 27, 2013 at 11:41 AM, Sebastian Bergmann wrote: > Am 27.05.2013 12:39, schrieb Michael Wallner: > > All previous MAINtainers are gone and there does not seem to be a lot > > of objection, so I'll start the +1s for a new & willing contributor: > > +1 :) > > -- > Sebastian Bergmann

Re: [PHP-DEV] Maintaining Phar

Am 27.05.2013 12:39, schrieb Michael Wallner: > All previous MAINtainers are gone and there does not seem to be a lot > of objection, so I'll start the +1s for a new & willing contributor: +1 :) -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergma

Re: [PHP-DEV] Maintaining Phar

On 25 May 2013 20:48, Ferenc Kovacs wrote: > On Sat, May 25, 2013 at 7:40 PM, Ralph Schindler > wrote: > >> I've asked previously (http://marc.info/?l=php-** >> internals&m=132096254304189&w=**2), >> but have not given commit karma for the p

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

Sanford Whiteman wrote: I'm not talking about storage time zone; we use UTC for that. I'm talking about the default display time zone. Unless we are misunderstanding each other (not unlikely given how this thread has sprawled) you seem to be saying the display time zone should be UTC by default a

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On 2013-05-27 11:00, Sanford Whiteman wrote: I'm not talking about storage time zone; we use UTC for that. I'm talking about the default display time zone. Don't you think that using proper calculations for displaying dates are application developers' responsibility? Whether is it setting a pr

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

> And if you think 'London time' is UTC then you will get just as > many problems half of tbe year. I said the *end user will assume* UTC timestamps are London time. Not that London time is UTC. People try to fit what they see into something they know. People in US-East see stuff 4-5 hours off, t

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On Mon, May 27, 2013 at 10:35 AM, Jannik Zschiesche wrote: > would it be hard to just show the notice as soon as the user actually uses > a function regarding to date/time (and not before)? > > Currently the message is shown all the time, at the start of the script - > even if the script is as sim

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

Hello, Am Montag, 27. Mai 2013 um 09:27 schrieb Pierre Joye: > On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman > (mailto:swhitemanlistens-softw...@cypressintegrated.com)> wrote: > > > I am simply making the point that UTC is not the "default default" > > even when sysops or devs put their h

Re: [PHP-DEV] Proposal for better UTF-8 handling

Btw, I hit a bug on grapheme_substr() that got no attention: https://bugs.php.net/bug.php?id=62759 There is also https://bugs.php.net/bug.php?id=61860 that waits for a fix. Nicolas On Mon, May 27, 2013 at 8:40 AM, Pierre Joye wrote: > hi! > > On Fri, May 24, 2013 at 3:17 AM, Rouven Weßling

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

> In my opinion UTC is a good compromise. I agree that _in the absence of any other setting_ there's nothing wrong with using UTC! Let be clear: UTC is a perfectly fine hands-off default rather than issuing a warning. Non-technical end users will guess you're on London time but whatever. And if

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On Mon, May 27, 2013 at 9:27 AM, Pierre Joye wrote: > On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman > wrote: > > > I am simply making the point that UTC is not the "default default" > > even when sysops or devs put their hands in. The choice isn't just UTC > > or what the end user personally

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On 2013-05-27 08:49, Reinis Rozitis wrote: Again, why can't we just bypass this whole argument by adding a configure option? Something like --date.default_timezone="America/Los_Angeles"? It could then build that in so it'll assume that if there's no php.ini or if it's just not set in there. Pr

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman wrote: > I am simply making the point that UTC is not the "default default" > even when sysops or devs put their hands in. The choice isn't just UTC > or what the end user personally sets. Domain time exists, no matter if > Pierre has experienced

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

> In my opinion UTC is a good compromise. I agree that _in the absence of any other setting_ there's nothing wrong with using UTC! Let be clear: UTC is a perfectly fine hands-off default rather than issuing a warning. Non-technical end users will guess you're on London time but whatever. I am s

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On Sun, May 26, 2013 at 11:49 PM, Reinis Rozitis wrote: > Again, why can't we just bypass this whole argument by adding a configure >> option? Something like --date.default_timezone="**America/Los_Angeles"? >> It >> could then build that in so it'll assume that if there's no php.ini or if >> it