Re: [PHP-DEV] ext/mysql in PECL and E_DEPRECATED

[Kris Craig]

On Thu, Nov 29, 2012 at 3:57 PM, David Muir  wrote:

> On 30/11/12 05:25, Ángel González wrote:
> > On 29/11/12 18:17, Anthony Ferrara wrote:
> >> Just pointing this out: that's NOT what this RFC recommends, and is
> >> NOT what's being voted on. This RFC is talking about ONLY adding
> >> E_DEPRECATED to core. And the way it's proposed to be done, the
> >> "moves-to-PECL" couldn't happen, since it's hard-coded into the core
> >> extension...
> >>
> >> So be careful what you're voting for...
> > The RFC doesn't state if/when ext/mysql should be moved to pecl or if it
> > should or not throw E_DEPRECATED there.
> > It was stated in one of the previous threads that:
> > - The extension would be moved to PECL when removed from core.
> > - It's ok if you want to use ext/mysql from pecl as it's "unsupported"
> > and your own problem, not one of php developers.
> >
> > There were also concerns that throwing E_DEPRECATED didn't allow to
> > cleanly use it (if you really wanted to) as if it was simply moved to
> pecl.
> >
> > I was presenting a way to throw E_DEPRECATED (assuming that option wins
> > in the RFC) while also allowing an extension (typically hosted on PECL)
> > to “provide” the non-E_DEPRECATED extension.
> >
> > If you take a closer look, you will see that it can happen, as long as
> > the core deprecation is done in that way, anticipating usage of that
> > pecl extension. (Note that it is a variable which could only be changed
> > by another extension, I wasn't proposing the ini_set mentioned by Alan,
> > IMHO that's an uglier solution, since everybody would end up setting it).
> >
> > You are of course welcome to point out any failures in the pseudo-code I
> > presented. :)
> > There would be a dependency on ELF-like binaries if using weak symbols.
> > But the version removing ext/mysql will likely have a different ABI
> > anyway, so it's not a big problem to require a recompile of pecl/mysql
> > for the different php version.
> >
>
> This is exactly why it doesn't make sense to have a vote on E_DEPRECATED
> without understanding what the future action will be.
>
> I might have missed some as there was no summary of the discussion in
> the RFC, or a summary of the various positions. This should have been
> added before calling a vote. Combined with future action, the various
> positions as I've read them are:
>
> 1. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and stop throwing
> E_DEPRECATED
> 2. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and continue
> throwing E_DEPRECATED
> 3. Move to PECL in 5.5 or 5.NEXT, and not throw E_DEPRECATED
> 4. Throw E_DEPRECATED in 5.5. Remove from core and PECL in 5.NEXT
>
> #1 means it's not really being deprecated
> #2 kind of makes sense, but then why even move it to PECL?
> #3 is consistent with current release RFC process
> #4 is the type of case E_DEPRECATED is meant to handle (or has handled
> thus far)
>
> The current release process RFC states:
>
>   *
> *x.y.z to x.y+1.z*
>   o
> Bugfixes
>   o
> New features
>   o
> *Extensions support can be ended (moved to pecl)*
>   o
> Backward compatibility must be kept
>   o
> API compatibility must be kept (userland)
>   o
> ABI and API can be broken (internals), src compatibility
> should be kept if possible, while breakages are allowed
>
> [emphasis mine]
>
> Some are saying that that E_DEPRECATED can/should be used for entire
> extensions. That's fine and dandy if said extension is actually going to
> be removed (not just retired to PECL, but dropped completely), but
> somehow I think a lot more people would object to the current RFC if
> that were the plan.
>
> Cheers,
> David
>

I don't think it would be appropriate to remove ext/mysql (whether
completely or just moved to PECL) at any point in the 5.x branch.  My
thinking is that 6.0 would be the time for major changes/BC like that to
take place.  Since that's probably still a ways off, my understanding was
that we're limiting the scope to what should happen in 5.x in the form of
deprecation/transition.  If you don't think it should be [re]moved at all,
then I would assume you'd want to vote no on deprecation anyway.  And if
you do think it should be taken out in some form or another, then either
way deprecation prior to doing so would be the most sensible approach
IMNSHO.  That's why it seems logical to me that we first decide on
when/whether to deprecate, then as we get closer to the next major version
increment we can figure out how best to dispose of it (assuming we voted to
deprecate in the first place).

--Kris

Re: [PHP-DEV] ext/mysql in PECL and E_DEPRECATED

[David Muir]

On 30/11/12 05:25, Ángel González wrote:
> On 29/11/12 18:17, Anthony Ferrara wrote:
>> Just pointing this out: that's NOT what this RFC recommends, and is
>> NOT what's being voted on. This RFC is talking about ONLY adding
>> E_DEPRECATED to core. And the way it's proposed to be done, the
>> "moves-to-PECL" couldn't happen, since it's hard-coded into the core
>> extension...
>>
>> So be careful what you're voting for...
> The RFC doesn't state if/when ext/mysql should be moved to pecl or if it
> should or not throw E_DEPRECATED there.
> It was stated in one of the previous threads that:
> - The extension would be moved to PECL when removed from core.
> - It's ok if you want to use ext/mysql from pecl as it's "unsupported"
> and your own problem, not one of php developers.
>
> There were also concerns that throwing E_DEPRECATED didn't allow to
> cleanly use it (if you really wanted to) as if it was simply moved to pecl.
>
> I was presenting a way to throw E_DEPRECATED (assuming that option wins
> in the RFC) while also allowing an extension (typically hosted on PECL)
> to “provide” the non-E_DEPRECATED extension.
>
> If you take a closer look, you will see that it can happen, as long as
> the core deprecation is done in that way, anticipating usage of that
> pecl extension. (Note that it is a variable which could only be changed
> by another extension, I wasn't proposing the ini_set mentioned by Alan,
> IMHO that's an uglier solution, since everybody would end up setting it).
>
> You are of course welcome to point out any failures in the pseudo-code I
> presented. :)
> There would be a dependency on ELF-like binaries if using weak symbols.
> But the version removing ext/mysql will likely have a different ABI
> anyway, so it's not a big problem to require a recompile of pecl/mysql
> for the different php version.
>

This is exactly why it doesn't make sense to have a vote on E_DEPRECATED
without understanding what the future action will be.

I might have missed some as there was no summary of the discussion in
the RFC, or a summary of the various positions. This should have been
added before calling a vote. Combined with future action, the various
positions as I've read them are:

1. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and stop throwing
E_DEPRECATED
2. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and continue
throwing E_DEPRECATED
3. Move to PECL in 5.5 or 5.NEXT, and not throw E_DEPRECATED
4. Throw E_DEPRECATED in 5.5. Remove from core and PECL in 5.NEXT

#1 means it's not really being deprecated
#2 kind of makes sense, but then why even move it to PECL?
#3 is consistent with current release RFC process
#4 is the type of case E_DEPRECATED is meant to handle (or has handled
thus far)

The current release process RFC states:

  *
*x.y.z to x.y+1.z*
  o
Bugfixes
  o
New features
  o
*Extensions support can be ended (moved to pecl)*
  o
Backward compatibility must be kept
  o
API compatibility must be kept (userland)
  o
ABI and API can be broken (internals), src compatibility
should be kept if possible, while breakages are allowed

[emphasis mine]

Some are saying that that E_DEPRECATED can/should be used for entire
extensions. That's fine and dandy if said extension is actually going to
be removed (not just retired to PECL, but dropped completely), but
somehow I think a lot more people would object to the current RFC if
that were the plan.

Cheers,
David

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Pierre Joye]

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 flurry of E_DEPRECATED warnings (if display_errors was
>>set to on) being triggered as of 5.3 due to their continued use of
>>magic_quotes_gpc and magic_quotes_runtime.  When Drupal 8 was released some
>>time later, the code was fixed so that it no longer used those out-dated
>>functions.
>
> http://drupal.org/community-initiatives/drupal-core
> Drupal 8 will not be released before August 2013. Maybe in the current
> core the E_DEPRECATED warnings are gone, but certainly not in many of
> the modules.

Drupal 7 supports PDO. There is no such thing like mysqli or mysql as driver.

> People are still switching to Drupal7. And Drupal7 throws the watchdog
> full with E_DEPRECATED warnings when it is running onder PHP5.4. The
> views module has issues with PHP 5.4, but some modules even let Drupal7
> under PHP5.4 crash completely:
> http://drupal.org/node/1831402

If there is a crash, a bug at bugs.php.net should be reported.

> If E_DEPRECATED stays in ext/mysql even after it has moved to PECL, the
> result will be that more and more people turn E_DEPRECATED warnings off.

And? Where is the problem? The idea is to have it on in dev not in prod.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Peter Cowburn]

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,
per the release process RFC that was agreed to.

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

Re: [PHP-DEV] ext/mysql in PECL and E_DEPRECATED

[Ángel González]

On 29/11/12 18:17, Anthony Ferrara wrote:
> Just pointing this out: that's NOT what this RFC recommends, and is
> NOT what's being voted on. This RFC is talking about ONLY adding
> E_DEPRECATED to core. And the way it's proposed to be done, the
> "moves-to-PECL" couldn't happen, since it's hard-coded into the core
> extension...
>
> So be careful what you're voting for...
The RFC doesn't state if/when ext/mysql should be moved to pecl or if it
should or not throw E_DEPRECATED there.
It was stated in one of the previous threads that:
- The extension would be moved to PECL when removed from core.
- It's ok if you want to use ext/mysql from pecl as it's "unsupported"
and your own problem, not one of php developers.

There were also concerns that throwing E_DEPRECATED didn't allow to
cleanly use it (if you really wanted to) as if it was simply moved to pecl.

I was presenting a way to throw E_DEPRECATED (assuming that option wins
in the RFC) while also allowing an extension (typically hosted on PECL)
to “provide” the non-E_DEPRECATED extension.

If you take a closer look, you will see that it can happen, as long as
the core deprecation is done in that way, anticipating usage of that
pecl extension. (Note that it is a variable which could only be changed
by another extension, I wasn't proposing the ini_set mentioned by Alan,
IMHO that's an uglier solution, since everybody would end up setting it).

You are of course welcome to point out any failures in the pseudo-code I
presented. :)
There would be a dependency on ELF-like binaries if using weak symbols.
But the version removing ext/mysql will likely have a different ABI
anyway, so it's not a big problem to require a recompile of pecl/mysql
for the different php version.


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

Re: [PHP-DEV] SplDoublyLinkedList missing insertBefore/After

[Daniel Ribeiro Gomes]

It would be an awesome feature, indeed.


Daniel Ribeiro Gomes Pereira
Twitter  |
Facebook
 | LinkedIn 
iPhone: +55 (48) 9111-0931



2012/11/29 Levi Morrison 

> On Thu, Nov 29, 2012 at 4:38 AM, Rafael Dohms 
> wrote:
> > I have just noticed that the current SPL inplementation of a
> > DoublyLinkedList does not include methods to insert nodes into the middle
> > of the list (insertBefore, insertAfter).
> >
> > After mentioning it I ran into a few people and other outbursts on the
> > internet of more people who saw this and complained about it.
> >
> > I found a bug from 2009 (https://bugs.php.net/bug.php?id=48358) which
> > mentions the case and has no Core response at all.
> >
> > I ask two questions:
> >
> > 1) Why was this bug never replied to, is there some reason these methods
> > should not be implemented?
> >
> > 2) Is anyone willing to put up a patch for this? I imagine that if you
> are
> > familiar with C and PHP source this is a quick implementation as its
> > standard logic documented everywhere.
>
> I am creating a library in PHP code that includes a linked list with
> this feature (
> https://github.com/morrisonlevi/PHP-Datastructures/blob/master/src/Spl/LinkedList.php
> ).
> I'd love for you to use it while you wait for the core to be patched
> and give me some feedback.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Kris Craig]

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 distros
>> have even slower adoption rates than PHP.  In fact, the opposite seems to
>> be true from what I've observed.
>>
>> In other words, most of these people you referenced who are still using
>> Drupal 6 are probably still using an older version of PHP as well.
>>  Therefore, most people using Drupal 7 probably don't have to worry about
>> the deprecation because they haven't upgraded to 5.3.3+ yet.  But it did
>> affect enough people that it forced the Drupal devs to update their code
>> to
>> conform to the changes in PHP.
>>
>> We shouldn't be targetting future PHP releases to sync with older distros
>> simply because many people still use them.  Given that most people tend to
>> use older versions of PHP as well, I believe it's safe to say that the two
>> cancel one another out.
>>
>
> In my opinion, this attitude is the exact wrong one for core to take. We
> should be trying to make adoption easier and removing barriers to projects
> and hosts upgrading, not relying on the fact that they don't to justify our
> actions.
>
> If we make the lives easier for developers and hosts, then we won't have
> the problems of lagging adoption. If we rely on the lagging adoption to
> justify changes, then the circle feeds itself.
>
> We shouldn't be relying on slow adoption for ANY decision. By doing that,
> we're ensuring slow adoption. And slow adoption hurts EVERYONE. It hurts us
> from the standpoint that we need to maintain software longer (or at least
> there's pressure to). It hurts us from the standpoint that feedback on new
> versions is reduced significantly. It hurts developers in that they can't
> take advantage of new features. It hurts developer because software doesn't
> get fixed for a long time. It hurts projects because they can't take
> advantage of new features for a long time. It hurts hosts in that they
> can't take advantage of performance improvements (that are sometimes very
> significant).
>
> The only group that benefits from long adoption cycles is the linux
> distribution folks. Because the longer it takes for our stuff to get
> adopted, the more it seems like their decision to have a long term version
> sane. But if adoption of new versions is as seamless as possible, and easy
> on everyone, then it makes that decision seem archaic and arbitrary.
>
> Low barriers means everyone wins. High barriers
> just exacerbates everyone's pain.
>
> Let's push for low barriers...
>
> Anthony
>

I do agree with you in principle, Anthony.  What I'm saying is that the
reality !== the ideal.  Slow adoption is just a fact of life.  Every IT
person I've ever worked with was trained to be cautious and to "go with
what we know is stable and works, not with what's new."  If distros like
Drupal were to get fast adoption and we were to get fast adoption, then
that would be super awesome.  So long as out adoption rate isn't faster
than theirs (which I don't think it would be even if we tried), then these
barriers will not exist for most people because the distros will update
themselves to conform to PHP long before they ever upgrade anyway.

--Kris

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Anthony Ferrara]

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 opposite seems to
> be true from what I've observed.
>
> In other words, most of these people you referenced who are still using
> Drupal 6 are probably still using an older version of PHP as well.
>  Therefore, most people using Drupal 7 probably don't have to worry about
> the deprecation because they haven't upgraded to 5.3.3+ yet.  But it did
> affect enough people that it forced the Drupal devs to update their code to
> conform to the changes in PHP.
>
> We shouldn't be targetting future PHP releases to sync with older distros
> simply because many people still use them.  Given that most people tend to
> use older versions of PHP as well, I believe it's safe to say that the two
> cancel one another out.
>

In my opinion, this attitude is the exact wrong one for core to take. We
should be trying to make adoption easier and removing barriers to projects
and hosts upgrading, not relying on the fact that they don't to justify our
actions.

If we make the lives easier for developers and hosts, then we won't have
the problems of lagging adoption. If we rely on the lagging adoption to
justify changes, then the circle feeds itself.

We shouldn't be relying on slow adoption for ANY decision. By doing that,
we're ensuring slow adoption. And slow adoption hurts EVERYONE. It hurts us
from the standpoint that we need to maintain software longer (or at least
there's pressure to). It hurts us from the standpoint that feedback on new
versions is reduced significantly. It hurts developers in that they can't
take advantage of new features. It hurts developer because software doesn't
get fixed for a long time. It hurts projects because they can't take
advantage of new features for a long time. It hurts hosts in that they
can't take advantage of performance improvements (that are sometimes very
significant).

The only group that benefits from long adoption cycles is the linux
distribution folks. Because the longer it takes for our stuff to get
adopted, the more it seems like their decision to have a long term version
sane. But if adoption of new versions is as seamless as possible, and easy
on everyone, then it makes that decision seem archaic and arbitrary.

Low barriers means everyone wins. High barriers just exacerbates everyone's
pain.

Let's push for low barriers...

Anthony

Re: [PHP-DEV] SplDoublyLinkedList missing insertBefore/After

[Levi Morrison]

On Thu, Nov 29, 2012 at 4:38 AM, Rafael Dohms  wrote:
> I have just noticed that the current SPL inplementation of a
> DoublyLinkedList does not include methods to insert nodes into the middle
> of the list (insertBefore, insertAfter).
>
> After mentioning it I ran into a few people and other outbursts on the
> internet of more people who saw this and complained about it.
>
> I found a bug from 2009 (https://bugs.php.net/bug.php?id=48358) which
> mentions the case and has no Core response at all.
>
> I ask two questions:
>
> 1) Why was this bug never replied to, is there some reason these methods
> should not be implemented?
>
> 2) Is anyone willing to put up a patch for this? I imagine that if you are
> familiar with C and PHP source this is a quick implementation as its
> standard logic documented everywhere.

I am creating a library in PHP code that includes a linked list with
this feature 
(https://github.com/morrisonlevi/PHP-Datastructures/blob/master/src/Spl/LinkedList.php).
I'd love for you to use it while you wait for the core to be patched
and give me some feedback.

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

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Kris Craig]

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 flurry of E_DEPRECATED warnings (if display_errors was
> >set to on) being triggered as of 5.3 due to their continued use of
> >magic_quotes_gpc and magic_quotes_runtime.  When Drupal 8 was released
> some
> >time later, the code was fixed so that it no longer used those out-dated
> >functions.
>
> http://drupal.org/community-initiatives/drupal-core
> Drupal 8 will not be released before August 2013. Maybe in the current
> core the E_DEPRECATED warnings are gone, but certainly not in many of
> the modules.
>
> People are still switching to Drupal7. And Drupal7 throws the watchdog
> full with E_DEPRECATED warnings when it is running onder PHP5.4. The
> views module has issues with PHP 5.4, but some modules even let Drupal7
> under PHP5.4 crash completely:
> http://drupal.org/node/1831402
>
> If E_DEPRECATED stays in ext/mysql even after it has moved to PECL, the
> result will be that more and more people turn E_DEPRECATED warnings off.
>

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 opposite seems to
be true from what I've observed.

In other words, most of these people you referenced who are still using
Drupal 6 are probably still using an older version of PHP as well.
 Therefore, most people using Drupal 7 probably don't have to worry about
the deprecation because they haven't upgraded to 5.3.3+ yet.  But it did
affect enough people that it forced the Drupal devs to update their code to
conform to the changes in PHP.

We shouldn't be targetting future PHP releases to sync with older distros
simply because many people still use them.  Given that most people tend to
use older versions of PHP as well, I believe it's safe to say that the two
cancel one another out.

--Kris

Re: [PHP-DEV] ext/mysql in PECL and E_DEPRECATED

[Anthony Ferrara]

Angel

On Thu, Nov 29, 2012 at 12:02 PM, Ángel González  wrote:

> David Muir wrote:
> > On 29/11/12 05:09, Ángel González wrote:
> >> I see it as simple to show E_DEPRECATED but not when installed from
> >> PECL.
> >>
> >> 1) Add a
> >> int mysql_extension_triggers_deprecated_warning = 1;
> >>
> >> And use it as a conditional for triggering the warning.
> >>
> >> 2) Copy the extension code to PECL
> >>
> >> 3) Add these changes in PECL
> >> - If the mysql functions are not already registered,
> >> register them with the bundled code.
> >> - Set mysql_extension_triggers_deprecated_warning = 0;
> >>
> >> 4) That's it.
> >>
> >
> > Then people (distros, hosts, etc) will just install it from PECL
> > instead to avoid all the E_DEPRECATED mess.
> >
> > David
> That's the goal.
> If they really want the extension they can install it from PECL and they
> don't get the E_DEPRECATED since that's not coming from core.
>
> No triggers-warning, moves-to-PECL, no-longer-triggers.
>
> It also provides a supported procedure for installing ext/mysql other
> than patching php to skip the warning. When someone complains about how
> they can only use ext/mysql (eg. they are using a code-protected script
> which uses ext/mysql and is critical for their business...), you can
> point to PECL, as well as explaining how it doesn't have the same
> guarantees as php core.


Just pointing this out: that's NOT what this RFC recommends, and is NOT
what's being voted on. This RFC is talking about ONLY adding E_DEPRECATED
to core. And the way it's proposed to be done, the "moves-to-PECL" couldn't
happen, since it's hard-coded into the core extension...

So be careful what you're voting for...

Re: [PHP-DEV] ext/mysql in PECL and E_DEPRECATED

[Ángel González]

David Muir wrote:
> On 29/11/12 05:09, Ángel González wrote:
>> I see it as simple to show E_DEPRECATED but not when installed from
>> PECL.
>>
>> 1) Add a
>> int mysql_extension_triggers_deprecated_warning = 1;
>>
>> And use it as a conditional for triggering the warning.
>>
>> 2) Copy the extension code to PECL
>>
>> 3) Add these changes in PECL
>> - If the mysql functions are not already registered,
>> register them with the bundled code.
>> - Set mysql_extension_triggers_deprecated_warning = 0;
>>
>> 4) That's it.
>>
>
> Then people (distros, hosts, etc) will just install it from PECL
> instead to avoid all the E_DEPRECATED mess.
>
> David
That's the goal.
If they really want the extension they can install it from PECL and they
don't get the E_DEPRECATED since that's not coming from core.

No triggers-warning, moves-to-PECL, no-longer-triggers.

It also provides a supported procedure for installing ext/mysql other
than patching php to skip the warning. When someone complains about how
they can only use ext/mysql (eg. they are using a code-protected script
which uses ext/mysql and is critical for their business...), you can
point to PECL, as well as explaining how it doesn't have the same
guarantees as php core.



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

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Remi Collet]

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 noice.



Regards,
Remi.


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

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Jan Ehrhardt]

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) being triggered as of 5.3 due to their continued use of
>magic_quotes_gpc and magic_quotes_runtime.  When Drupal 8 was released some
>time later, the code was fixed so that it no longer used those out-dated
>functions.

http://drupal.org/community-initiatives/drupal-core
Drupal 8 will not be released before August 2013. Maybe in the current
core the E_DEPRECATED warnings are gone, but certainly not in many of
the modules.

People are still switching to Drupal7. And Drupal7 throws the watchdog
full with E_DEPRECATED warnings when it is running onder PHP5.4. The
views module has issues with PHP 5.4, but some modules even let Drupal7
under PHP5.4 crash completely:
http://drupal.org/node/1831402

If E_DEPRECATED stays in ext/mysql even after it has moved to PECL, the
result will be that more and more people turn E_DEPRECATED warnings off.

Jan

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

Re: [PHP-DEV] DOMNodeList memory eating

[Rob Richards]

XPath returns a fully populated list of object based on the expression. 
getElementsByTagName accesses the nodes within the tree in real time as 
you iterate so you only have one object at a time unless you are 
persisting them. Different behavior due to who owns the data and its 
lifecycle. XPath data is strictly owned by libxml while the underlying 
data from getElementsByTagName can be managed by PHP.


Rob

On 11/29/12 8:36 AM, Nicolai Scheer wrote:

Hi!

Just stumbled upon a strange behaviour when iterating over DOMNodeLists.
Before I open a bug report I'd like to ask if anyone can comment on this
issue, maybe it's the excpected behaviour.

Consider the following small script:



 x
 x
 x

XML;

$dom = new DOMDocument();
$dom->loadXML( $xml );
$xpath = new DOMXPath( $dom );

while ( true )
{
 # 1. memory eater...
 $link_object_list = $xpath->query( '//node' );

 # 2. constant memory usage
 #$link_object_list = $dom->getElementsByTagName( 'node' );

 foreach ( $link_object_list as $value )
 {
 while ( true )
 {
 $link = $link_object_list->item( 0 );
 }
 }
}

?>


Strange thing is, if the DomNodeList is produced by the xpath query, the
script eats memory. If I use getElementsByTagName to get the list memory
usage is constant.

$value holds the object handle for the first NodeItem. If another list
element is accessed (e.g. the second one) the usage is constant as well
(both cases).

Seems as if there's something strange going on with object handles and / or
wrong garbage collection. Or maybe I'm just confusing things here ;)

Any comments?

Greetings

Nico




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

[PHP-DEV] DOMNodeList memory eating

[Nicolai Scheer]

Hi!

Just stumbled upon a strange behaviour when iterating over DOMNodeLists.
Before I open a bug report I'd like to ask if anyone can comment on this
issue, maybe it's the excpected behaviour.

Consider the following small script:



x
x
x

XML;

$dom = new DOMDocument();
$dom->loadXML( $xml );
$xpath = new DOMXPath( $dom );

while ( true )
{
# 1. memory eater...
$link_object_list = $xpath->query( '//node' );

# 2. constant memory usage
#$link_object_list = $dom->getElementsByTagName( 'node' );

foreach ( $link_object_list as $value )
{
while ( true )
{
$link = $link_object_list->item( 0 );
}
}
}

?>


Strange thing is, if the DomNodeList is produced by the xpath query, the
script eats memory. If I use getElementsByTagName to get the list memory
usage is constant.

$value holds the object handle for the first NodeItem. If another list
element is accessed (e.g. the second one) the usage is constant as well
(both cases).

Seems as if there's something strange going on with object handles and / or
wrong garbage collection. Or maybe I'm just confusing things here ;)

Any comments?

Greetings

Nico

Re: [PHP-DEV] SplDoublyLinkedList missing insertBefore/After

[Paul Dragoonis]

Hi Rafael,

I have worked on this code before and if the idea is accepted I'm happy to
add features to this class.

Let me know.
Thanks,
Paul.


On Thu, Nov 29, 2012 at 11:38 AM, Rafael Dohms wrote:

> I have just noticed that the current SPL inplementation of a
> DoublyLinkedList does not include methods to insert nodes into the middle
> of the list (insertBefore, insertAfter).
>
> After mentioning it I ran into a few people and other outbursts on the
> internet of more people who saw this and complained about it.
>
> I found a bug from 2009 (https://bugs.php.net/bug.php?id=48358) which
> mentions the case and has no Core response at all.
>
> I ask two questions:
>
> 1) Why was this bug never replied to, is there some reason these methods
> should not be implemented?
>
> 2) Is anyone willing to put up a patch for this? I imagine that if you are
> familiar with C and PHP source this is a quick implementation as its
> standard logic documented everywhere.
>
> I'm not familiar enough with the PHP source to do this myself, hence I'm
> asking for anyone willing to "champion" the patch.
>
> Thanks!
>
> --
> Rafael Dohms
> PHP Evangelist and Community Leader
> http://www.rafaeldohms.com.br
> http://www.amsterdamphp.nl
>

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Johannes Schlüter]

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
>- ext/msql
>- ext/sybase
> 
> 
> Now you could make the argument that they weren't as used as ext/mysql. But
> they were removed from core without raising E_DEPRECATED first.

There is another argument: Those aren't deprecated. They were just
moved. Aside from mhash it is still fine to use those, we simply don't
bundle them anymore. For mhash there is an equivalent replacement in the
distribution.

With ext/mysql it is about "don't use this anymore. Use mysqli or such"

johannes



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

[PHP-DEV] SplDoublyLinkedList missing insertBefore/After

[Rafael Dohms]

I have just noticed that the current SPL inplementation of a
DoublyLinkedList does not include methods to insert nodes into the middle
of the list (insertBefore, insertAfter).

After mentioning it I ran into a few people and other outbursts on the
internet of more people who saw this and complained about it.

I found a bug from 2009 (https://bugs.php.net/bug.php?id=48358) which
mentions the case and has no Core response at all.

I ask two questions:

1) Why was this bug never replied to, is there some reason these methods
should not be implemented?

2) Is anyone willing to put up a patch for this? I imagine that if you are
familiar with C and PHP source this is a quick implementation as its
standard logic documented everywhere.

I'm not familiar enough with the PHP source to do this myself, hence I'm
asking for anyone willing to "champion" the patch.

Thanks!

-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.amsterdamphp.nl

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Chris van Dam]

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 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 were
>>moved to
>> PECL:
>>
>>
>>- ext/dbase
>>- ext/fbsql
>>- ext/fdf
>>- ext/ncurses
>>- ext/mhash (BC layer is now entirely within ext/hash)
>>- ext/ming
>>- ext/msql
>>- ext/sybase
>>
>> Now you could make the argument that they weren't as used as ext/mysql.
>>But
>> they were removed from core without raising E_DEPRECATED first.
>
>Back to this time, there was no release RFC and it was a simple +/- 1
>vote to get an extension out of the distributions. So it is hardly
>comparable to the current situation.
>
>> So there definitely is precedent to remove without deprecating first. So
>> it's completely within the realm of discussion here.
>
>No there is not one, not since the RFC introduction. Removing
>extension in minor (x.y+1 or x.y.z+1) is not allowed.
>
>
>> The problem with this statement is that you're indicating something that
>> didn't happen. "get the word out" campaigns have not happened on an
>> official level for ext/mysql. The wording in the docs is light at best.
>> There has been very little effort from the side of the project to say
>>"get
>> off it now". And that's what some of us have against this concept of
>> raising E_DEPRECATED in 5.5 (or possibly ever)...
>
>With the risk to repeat myself here (like 99.99% of the posts in this
>thread), almost all major projects out there have zero issue with the
>deprecation flag. They even agree to get it as it will help to
>convince their developers and users to update their code and setups.
>
>Cheers,
>--
>Pierre
>
>@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php
>


E-mail disclaimer Nederlands
De informatie verzonden met dit e-mailbericht is vertrouwelijk en kan wettelijk 
voorbehouden zijn. Het is uitsluitend bestemd voor de geadresseerde. Gebruik 
van deze informatie door anderen dan de geadresseerde en zij die gerechtigd 
zijn daarvan kennis te nemen is verboden. Trace staat niet in voor de juiste en 
volledige overbrenging van de inhoud van een verzonden e-mail, noch voor 
tijdige ontvangst daarvan.
E-mail disclaimer English
The information contained in this communication is confidential and may be 
legally privileged. It is intended solely for the use of the individual or 
entity to whom it is addressed and others authorized to receive it. The use of 
it by others is prohibited. Trace is neither liable for the proper and complete 
transmission of the information contained in this communication nor for any 
delay in its receipt.


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

Re: [PHP-DEV] Bug 61272

[Michael Wallner]

On 29 November 2012 08:00, Yasuo Ohgaki  wrote:

> I recently looked into new output code in PHP 5.4.
> It's MUCH nicer than older code. Good job!

Appreciated!

> However, new code encapsulate output globals. (I mean internally)
> It would be nice for my extension if output globals are exposed.

This was changed intentionally, why would you need OG what the API
does not provide?

> Exposing output global is not mandatory, though.



-- 
Regards,
Mike

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

Re: [PHP-DEV] ext/mysql in PECL and E_DEPRECATED

[Pierre Joye]

hi Alan!

On Thu, Nov 29, 2012 at 12:11 AM, Mailing list  wrote:
> .. annoying top posting...


Why do you top post too then? :)

> This is getting close to a good solution.
>
> ini option  mysql_is_deprecated - can not be set in .ini/htaccess etc, only
> by ini_set() - so hosters/distros can not fix it...

Are you asking to add an option to do exactly the same than the error
reporting option does?

> Normally added just before mysql_connect...
>
> ini_set('mysql_is_deprecated', "I WILL NOT USE IT IN THE FUTURE");

eror_reporting(...);
> mysql_connect(..)

> Solves:
> - Users will get warnings on upgrading - it can not be hidden by
> hosters/distros etc.
> - Users can easily disable the warning, however they will be explicitly
> aware of the problem.

Warning on install, on connect and in the doc is not enough? :)  And
once it is on pecl, we have the superseded/deprecated flag too there.
It won't help for distros but distros will follow app leads, as usual.
The only reason why distros still provide ext/mysql by default is
because the apps require it by default.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Pierre Joye]

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 were moved to
> PECL:
>
>
>- ext/dbase
>- ext/fbsql
>- ext/fdf
>- ext/ncurses
>- ext/mhash (BC layer is now entirely within ext/hash)
>- ext/ming
>- ext/msql
>- ext/sybase
>
> Now you could make the argument that they weren't as used as ext/mysql. But
> they were removed from core without raising E_DEPRECATED first.

Back to this time, there was no release RFC and it was a simple +/- 1
vote to get an extension out of the distributions. So it is hardly
comparable to the current situation.

> So there definitely is precedent to remove without deprecating first. So
> it's completely within the realm of discussion here.

No there is not one, not since the RFC introduction. Removing
extension in minor (x.y+1 or x.y.z+1) is not allowed.


> The problem with this statement is that you're indicating something that
> didn't happen. "get the word out" campaigns have not happened on an
> official level for ext/mysql. The wording in the docs is light at best.
> There has been very little effort from the side of the project to say "get
> off it now". And that's what some of us have against this concept of
> raising E_DEPRECATED in 5.5 (or possibly ever)...

With the risk to repeat myself here (like 99.99% of the posts in this
thread), almost all major projects out there have zero issue with the
deprecation flag. They even agree to get it as it will help to
convince their developers and users to update their code and setups.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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