[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-internals
Subject:    Re: [PHP-DEV] Re: svn: /php/php-src/trunk/ UPGRADING.INTERNALSext/date/php_date.c
From:       Derick Rethans <derick () php ! net>
Date:       2010-09-28 10:57:17
Message-ID: alpine.DEB.2.00.1009281155560.2461 () kossu ! derickrethans ! nl
[Download RAW message or body]

On Tue, 28 Sep 2010, Peter Cowburn wrote:

> On 28 September 2010 08:19, Michael Wallner <mike@php.net> wrote:
> > On 09/28/2010 07:05 AM, Kalle Sommer Nielsen wrote:
> >>
> >> 2010/9/27 Johannes Schlüter<johannes@schlueters.de>:
> >>>
> >>> I think Mike's point was that these functions, according to the comment,
> >>> only exist for BC reasons. So they should either keep BC or be dropped.
> >
> >> The only usage php_idate() exists for is the idate() function, i
> >> greped pecl and tried to use OpenGrok, but it was only used within the
> >> date extension, so i think the break is minor to nothing.
> >
> > So? Drop it or leave it alone :) idate() seems as useful as a nipple on my
> > back...
> 
> I use idate(), to this day, in preference of (int) date(). Whilst it's
> hardly a huge issue, dare I say many folks don't even know if its
> existence, if it is dropped, I may cross whomever does it off of my
> Christmas card list.

The idate() function isn't going to be dropped; we're just making sure 
it doesn't break BC here. And FWIF, I agree with Michael here: No need 
to break (internal) BC over such an unimportant thing.

Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[prev in list] [next in list] [prev in thread] [next in thread]