hi Jan,
On Thu, Nov 29, 2012 at 4:46 PM, Jan Ehrhardt wrote:
> Kris Craig in php.internals (Wed, 28 Nov 2012 12:33:55 -0800):
>>We also know that E_DEPRECATED works when other approaches do not. I would
>>point you all to the famous example of Drupal 7, which would break
>>completely due to a fl
On 29 November 2012 08:27, Pierre Joye wrote:
>
> No there is not [precedent to remove from core without deprecating first],
> not since the RFC introduction. Removing
> extension in minor (x.y+1 or x.y.z+1) is not allowed.
>
Moving an extension to PECL in a minor version increment is allowed,
p
On Thu, Nov 29, 2012 at 10:03 AM, Anthony Ferrara wrote:
> Kris
>
>
> I think you're forgetting though that the same applies to PHP itself. Many
>> repos still default to PHP 5.1.x. Adoption always tends to be a lagging
>> factor. I don't see any evidence to suggest that Drupal and other distro
Kris
I think you're forgetting though that the same applies to PHP itself. Many
> repos still default to PHP 5.1.x. Adoption always tends to be a lagging
> factor. I don't see any evidence to suggest that Drupal and other distros
> have even slower adoption rates than PHP. In fact, the opposi
On Thu, Nov 29, 2012 at 7:46 AM, Jan Ehrhardt wrote:
> Kris Craig in php.internals (Wed, 28 Nov 2012 12:33:55 -0800):
> >We also know that E_DEPRECATED works when other approaches do not. I
> would
> >point you all to the famous example of Drupal 7, which would break
> >completely due to a flurr
My 0,02€
Could it be possible to add in "deprecated" field in the
zend_module_entry structure,
add 0 value in STANDARD_MODULE_PROPERTIES_EX
add 1 value in DEPRECATED_MODULE_PROPERTIES_EX (new constant)
And then, only throw a message during initial module load.
This will produce really less noi
Kris Craig in php.internals (Wed, 28 Nov 2012 12:33:55 -0800):
>We also know that E_DEPRECATED works when other approaches do not. I would
>point you all to the famous example of Drupal 7, which would break
>completely due to a flurry of E_DEPRECATED warnings (if display_errors was
>set to on) bei
On Wed, 2012-11-28 at 23:28 -0500, Anthony Ferrara wrote:
> Case in point, take a look at 5.3.0. The following extensions were moved to
> PECL:
>
>
>- ext/dbase
>- ext/fbsql
>- ext/fdf
>- ext/ncurses
>- ext/mhash (BC layer is now entirely within ext/hash)
>- ext/ming
>
Hi Internals,
I think the E_DEPRECATED flag for this extension is fine, as it helps
tracking down the code which needs to be fixed.
Kind regards,
Chris van Dam
Op 29-11-12 09:27 schreef Pierre Joye :
>hi Anthony,
>
>As you are (relatively) new in php.net, let keep the history in mind
>while co
hi Anthony,
As you are (relatively) new in php.net, let keep the history in mind
while comparing things.
On Thu, Nov 29, 2012 at 5:28 AM, Anthony Ferrara wrote:
> Actually, it is very much within the scope of this discussion.
>
> Case in point, take a look at 5.3.0. The following extensions wer
Kris Craig wrote:
Either way, our common goal here is to get people to stop using ext/mysql now so
that we can trash it when the time comes. And as far as that goes, I think that
what happened with magic_quotes and Drupal is a perfect example of how
deprecation can effectively push devs to act w
Kris,
I disagree. Whether we're deprecating an extension or a subset of
> functions, the practical impact is pretty much the same. As for moving it
> to PECL, why are we even discussing that here? It's completely outside the
> scope of this RFC. I imagine moving it to PECL would make the most
> Kris,
>
> There was no "ext/magic_quotes" that was retired to PECL. You're comparing
> apples with oranges.
>
> David
>
>
I disagree. Whether we're deprecating an extension or a subset of
functions, the practical impact is pretty much the same. As for moving it
to PECL, why are we even discussi
On 29/11/12 07:33, Kris Craig wrote:
On Wed, Nov 28, 2012 at 8:43 AM, Anthony Ferrara wrote:
Patrick,
Sorry, but removing the E_DEPRECATED notice when moved to PECL is not
part of the proposed RFC and should certainly not happen.
The proposal doesn't actually propose anything about a move
On Wed, Nov 28, 2012 at 8:43 AM, Anthony Ferrara wrote:
> Patrick,
>
>
> Sorry, but removing the E_DEPRECATED notice when moved to PECL is not
> > part of the proposed RFC and should certainly not happen.
> >
>
> The proposal doesn't actually propose anything about a move to PECL. It's
> listed in
Patrick,
Sorry, but removing the E_DEPRECATED notice when moved to PECL is not
> part of the proposed RFC and should certainly not happen.
>
The proposal doesn't actually propose anything about a move to PECL. It's
listed in the "possible future actions" section exactly once. But the RFC
doesn't
From: Patrick ALLAERT
Sorry, but removing the E_DEPRECATED notice when moved to PECL is not part
of the proposed RFC and should certainly not happen.
I don't get what is the reason behind it?
Yes, the extension is old but it still works perfectly fine and even
outperforms the newer mysqli/pd
Patrick ALLAERT wrote:
2012/11/28 Lester Caine:
>There is no 'objection' to deprecating the extension, but adding
>E_DEPRECATED to the code is problematic since that should NOT be present in
>a PECL version of the code?
Sorry, but removing the E_DEPRECATED notice when moved to PECL is not
part
2012/11/28 Lester Caine :
> There is no 'objection' to deprecating the extension, but adding
> E_DEPRECATED to the code is problematic since that should NOT be present in
> a PECL version of the code?
Sorry, but removing the E_DEPRECATED notice when moved to PECL is not
part of the proposed RFC an
On Wed, Nov 28, 2012 at 11:30 AM, Philip Olson wrote:
> The idea of moving it to PECL is not represented in the vote. But
> it's something to consider as it's a real possibility. It could
> both symbolize that we are serious about not using ext/mysql, and
> considering most Linux distros would si
On Nov 28, 2012, at 2:08 AM, Pierre Joye wrote:
> hi,
>
> On Wed, Nov 28, 2012 at 10:55 AM, Alexey Zakhlestin
> wrote:
>> I voted "no", "(b)"
>> We should mention deprecation in manual as hard as possible, we should
>> mention it in ext/mysql/config.m4 and any other place we can reach.
>> Then
hi,
On Wed, Nov 28, 2012 at 10:55 AM, Alexey Zakhlestin wrote:
> I voted "no", "(b)"
> We should mention deprecation in manual as hard as possible, we should
> mention it in ext/mysql/config.m4 and any other place we can reach.
> Then, at some point (I'm fine with 5.6, but 6.0 would do also), we
I voted "no", "(b)"
We should mention deprecation in manual as hard as possible, we should
mention it in ext/mysql/config.m4 and any other place we can reach.
Then, at some point (I'm fine with 5.6, but 6.0 would do also), we
should just move it to PECL, without using E_DEPRECATED
--
Alexey Zakhle
Adam Harvey wrote:
Deprecation is a strong signal. It's a signal that it's time to update
tutorials. It's a signal to schedule upgrades for code when new
versions are written to use more modern APIs. It's a signal to those
of us who speak at conferences, and help people in various fora and
variou
On 28 November 2012 14:03, Adam Harvey wrote:
OK, so the first e-mail was the official announcement of voting being
open. I'd now like to quickly lay out why I voted yes, and why I think
it's the right way forward. Feel free to hit next if your mind is
already made up. :)
Ulf produced a blackly
25 matches
Mail list logo
