Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

[Clint Priest]

Yeah, pretty much.  I would not say they are "hidden" from the user, 
they are simply not revealed purposely.  (see example below for reason)  
It's an irrelevant engine implementation detail.  They would simply be 
callable only because they are actually methods. They are not magic 
methods because their simple existence does not make them accessors.


Fatal error: Call to private method a::__setb() from context ''...

Or...

Fatal error: Cannot set private property a::$b.

A user seeing the first error after having defined a property would be 
like WTF?  What is __setb() and why does the engine think I'm trying to 
call it?


As the code is currently written, nearly all errors that would have 
produced confusing errors such as the former, they produce errors such 
as the latter, one that makes sense given that they are trying to set a 
property.


Nikita, you and Stas are the two most diametrically opposed on this 
issue, would you please hash it out and let me know?  You all know my 
position on what I think it should do and I'd just like this to get 
resolved.


-Clint

On 11/14/2012 9:35 AM, Nikita Popov wrote:
On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest > wrote:


Been AWOL for a while and getting back to this, doesn't seem like
any resolution has occurred, just the conversation has died down.

I got the feeling that in the last few mails we actually made some 
progress and some people agreed with me that __magic accessor methods 
and a dedicated syntax for them are not combinable semantically. Maybe 
I got that wrong :/


I would propose that:

1) Internal accessor methods that are defined are callable directly.
2) Said methods are not reflected or revealed by the engine (stack
traces, reflection, etc would hide the engines implementation details)

I think that with the above, #1 makes it easy as no further
changes are required to make that happen, they're already directly
callable


The current implementation just uses the __ methods internally, but 
they are not actually magic accessor methods. That's not what Stas 
wants (as far as I understood). So you would still have to change the 
implementation to make them true magic methods which can be used 
independently from the special accessor syntax.


and #2 jives with what *most userland programmers* would expect.


So with your current plan we would end up with this:

a) A dedicated accessors syntax
b) which internally stores the accessors as methods with special names
c) but those methods are not magic methods, so you can't get the same 
behavior by defining them directly

d) and the methods are hidden from the user
e) but he can still call them (even though they don't exist if he asks 
for them in reflection).


All this sounds very odd to me.

Nikita :)


--
-Clint

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

[Clint Priest]

*sigh*

Which error would make more sense to you Stas...

Given this code:

class a {
public $b {
get() { return 5; }
private set($x) { /* do something */ }
}
}

$o = new a();

echo $o->b;
$o->b = 42;

There are two possibilities at this point.  The code base, without all 
the work I have done to make the errors make sense will show:


Fatal error: Call to private method a::__setb() from context ''...

Or...

Fatal error: Cannot set private property a::$b.

Which makes more sense to the most people?

On 11/14/2012 10:24 AM, Stas Malyshev wrote:

Hi!


Been AWOL for a while and getting back to this, doesn't seem like any
resolution has occurred, just the conversation has died down.

I would propose that:

1) Internal accessor methods that are defined are callable directly.
2) Said methods are not reflected or revealed by the engine (stack
traces, reflection, etc would hide the engines implementation details)

I think that with the above, #1 makes it easy as no further changes are
required to make that happen, they're already directly callable and #2
jives with what *most userland programmers* would expect.

Anyone disagree?

Yes. I strongly disagree with adding any magic to the engine that messes
with reflection and backtraces and removes methods existing and being
called from it. I think no "userland" programmer would have any problem
understanding that these methods exist and how they work, just as nobody
has problem understanding how __get works. I think adding this magic
complicates both engine code (which will have to be supported for years
to come) and the language, without absolutely any benefit to anybody
except for imaginary people being scared to death by methods that they
themselves defined showing up in the backtrace.



--
-Clint

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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Adam Harvey]

On 15 November 2012 08:36, Devis Lucato  wrote:
> Sorry if this was already suggested before: for people stuck on legacy
> applications and without money to upgrade (e.g. charities, user
> groups) a PECL extension would at least provide a way to survive.
> Forcing people to upgrade doesn't sound like an improvement but more
> of a way to push people away from the language.  Shouldn't this kind
> of "improvements" belong to major releases ?

Usually, when an extension is unbundled from PHP, it gets moved to
PECL. Theoretically, if somebody wanted to maintain it there, they
could volunteer and do so.

Again, though, this is a long way down the road: today's discussion is
purely about deprecation.

Adam

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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Devis Lucato]

Sorry if this was already suggested before: for people stuck on legacy
applications and without money to upgrade (e.g. charities, user
groups) a PECL extension would at least provide a way to survive.
Forcing people to upgrade doesn't sound like an improvement but more
of a way to push people away from the language.  Shouldn't this kind
of "improvements" belong to major releases ?

my 2c

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

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

[Patrick Schaaf]

On Wednesday 14 November 2012 16:35:31 Nikita Popov wrote:
> On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest  wrote:
> > Been AWOL for a while and getting back to this, doesn't seem like any
> > resolution has occurred, just the conversation has died down.
> 
> I got the feeling that in the last few mails we actually made some progress
> and some people agreed with me that __magic accessor methods and a
> dedicated syntax for them are not combinable semantically. Maybe I got that
> wrong :/

I thought I'd made a proposal that would solve that problem, but maybe it was 
overlooked, or more likely too ugly to be recognized as such.

Requires a single new feature / syntax, that at least I find missing right 
now:

class ... {
  no methodname();
   // or
  no $property;
}

removing the specified thing from the class, with the possibility to then 
redefine it. Silently ignore this when the thing doesn't exist.

The mechanism for that could then be used to solve your semantic puzzle, using 
these rules:

- any ordinary property declaration for $foo internally also does
no __prop_get_foo();
no __prop_set_foo();
no __prop_isset_foo();
no __prop_unset_foo();
- any declaration of these four new magic methods internally also does
   no $foo;

In other words:

whenever a class implements one of the accessor magic methods, an inherited 
property is ignored, as if it wasn't present in the base class(es) in the 
first place.

And whenever a class declares a property in the ordinary way, any inherited 
magic property accessor methods are ignored, as if they were not present in 
the base class(es) in the first place.

Maybe a "final" in the respective base class, would make this attempt an 
ERROR.

What do you think? Should I try to write up an RFC for the "no" feature?

best regards
  Patrick

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

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

[Stas Malyshev]

Hi!

> Been AWOL for a while and getting back to this, doesn't seem like any 
> resolution has occurred, just the conversation has died down.
> 
> I would propose that:
> 
> 1) Internal accessor methods that are defined are callable directly.
> 2) Said methods are not reflected or revealed by the engine (stack 
> traces, reflection, etc would hide the engines implementation details)
> 
> I think that with the above, #1 makes it easy as no further changes are 
> required to make that happen, they're already directly callable and #2 
> jives with what *most userland programmers* would expect.
> 
> Anyone disagree?

Yes. I strongly disagree with adding any magic to the engine that messes
with reflection and backtraces and removes methods existing and being
called from it. I think no "userland" programmer would have any problem
understanding that these methods exist and how they work, just as nobody
has problem understanding how __get works. I think adding this magic
complicates both engine code (which will have to be supported for years
to come) and the language, without absolutely any benefit to anybody
except for imaginary people being scared to death by methods that they
themselves defined showing up in the backtrace.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Ángel González]

Am 14/11/12 03:26, schrieb Michael Kliewe:
> Am 14.11.2012 00:23, schrieb Ángel González:
>> So the problem really moves onto the CMS providers, do they support
>> new php versions and drop customers in shared hosting, do they delay
>> supporting the new php versions, or do they reimplement mysql_*
>> in php?
> We are talking about ~1.5 years until ext/mysql is really removed.
> Don't you think all big project will be able to remove it during that
> timerange? And no big hosting provider will roll out that new version
> on day 1, so you will not see many hosters running PHP 5.6 (where
> ext/mysql is removed)  in the next 2 years. Enough time to get rid of
> the old mysql_* things.
>
> Deprecated warnings do not hurt anybody, in production environments
> they are not visible, so where is the problem? Nothing will break with
> 5.5
I disagree.

It's not true that they won't be visible in production environments
(although they shouldn't).

There are scripts doing error_reporting(E_ALL), then not looking at the
error_log they are spamming.

It's bad if developers disable E_DEPRECATED just to not see this
warnings (eg. theyare working in a project which has decided to continue
supporting ext/mysql) and due to that miss other deprecated notices.


Finally, this is the right time to discuss it.


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

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

[Nikita Popov]

On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest  wrote:

> Been AWOL for a while and getting back to this, doesn't seem like any
> resolution has occurred, just the conversation has died down.
>

I got the feeling that in the last few mails we actually made some progress
and some people agreed with me that __magic accessor methods and a
dedicated syntax for them are not combinable semantically. Maybe I got that
wrong :/

I would propose that:
>
> 1) Internal accessor methods that are defined are callable directly.
> 2) Said methods are not reflected or revealed by the engine (stack traces,
> reflection, etc would hide the engines implementation details)
>
> I think that with the above, #1 makes it easy as no further changes are
> required to make that happen, they're already directly callable


The current implementation just uses the __ methods internally, but they
are not actually magic accessor methods. That's not what Stas wants (as far
as I understood). So you would still have to change the implementation to
make them true magic methods which can be used independently from the
special accessor syntax.

and #2 jives with what *most userland programmers* would expect.
>

So with your current plan we would end up with this:

a) A dedicated accessors syntax
b) which internally stores the accessors as methods with special names
c) but those methods are not magic methods, so you can't get the same
behavior by defining them directly
d) and the methods are hidden from the user
e) but he can still call them (even though they don't exist if he asks for
them in reflection).

All this sounds very odd to me.

Nikita :)

RE: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

[Christian Stoller]

@ internal accessor method visibility / callability

I would prefer "Type 1" because:
1. A programming language is made for those who use the language not for those 
who develop this language. What is the target group of PHP?
2. Why should I define a property "protected $property { }" and call it via 
->__getProperty() ? If I would like to do that, I can define "public function 
__getProperty() { }"
3. The feature provides *property accessors* and not magic method generators
4. Providing internal accessor method callability could make code less readable 
and more complex, without adding any plus
5. This magic behavior blows up documentation and will make the whole topic 
more complicated for "beginners"
6. What happens if I define "protected $property { get() {...} }" and 
"protected function __getProperty() { }" in one class? 

I hope that does not sound aggressive ;)

Best regards
Christian


-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com] 
Sent: Wednesday, November 14, 2012 2:28 PM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method 
Visibility / Callability

Been AWOL for a while and getting back to this, doesn't seem like any 
resolution has occurred, just the conversation has died down.

I would propose that:

1) Internal accessor methods that are defined are callable directly.
2) Said methods are not reflected or revealed by the engine (stack 
traces, reflection, etc would hide the engines implementation details)

I think that with the above, #1 makes it easy as no further changes are 
required to make that happen, they're already directly callable and #2 
jives with what *most userland programmers* would expect.

Anyone disagree?

On 10/26/2012 5:37 AM, Clint Priest wrote:
> I'm opening up several new threads to get discussion going on the 
> remaining "being debated" categories referenced in this 1.1 -> 1.2 
> change spec:
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests 
>
>
> 
> Some people are in favor of the internal functions being generated by 
> an accessor declaration should be invisible and non-callable directly. 
> Others are in favor of leaving them visible and callable.
>
> *Type 1 ( Userland Programmer )**
> *
> As a userland programmer, someone who cares nothing for "how" php 
> works, only how their own code works. If they define an accessor they 
> expect to see an accessor, reflection should reflect that there are 
> accessors and no other "methods" they did not explicitly define. If 
> they were to reflect on all of the methods of their class and see a 
> number of __getHours() they may be confused as to why or where this 
> function came from. From their perspective, they have defined an 
> accessor and "how" that accessor works on the inside is of no 
> importance to them and only seeks to complicate or confuse matters 
> when they are exposed to these "implementation details" of the php 
> language its-self. If you tried to set a value such as $obj?abc = 1 
> through an accessor which could not be set, you would probably want to 
> see an error like: Warning, cannot set Class?abc, no setter defined.
>
> *Type 2 ( Internals Programmer )**
> *
> As an internals programmer, you want nothing hidden from you. If an 
> accessor implements special __getHours() methods to work its magic, 
> then you want to see them, you want to call them directly if you so 
> choose. In effect you want nothing hidden from you. In this case you 
> probably don't even want Reflection to reflect accessors as anything 
> different than specially formatted and called methods on the class. 
> This can be understandable because you want all information available 
> to you. You would probably not be confused if you wrote $obj?abc = 1 
> and got back an error like "Fatal Error: Class->__setAbc() function 
> does not exist.
>
> *Unfortunately 80 to 95% of all people who use PHP are of the first 
> type.**
> *
> Revealing these internal matters to them would only leave them 
> confused, possibly frustrated and likely asking about it to the 
> internals mailing list to answer (repeatedly).
> 
>
> Thoughts?
>

-- 
-Clint

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

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

[Clint Priest]

Been AWOL for a while and getting back to this, doesn't seem like any 
resolution has occurred, just the conversation has died down.


I would propose that:

1) Internal accessor methods that are defined are callable directly.
2) Said methods are not reflected or revealed by the engine (stack 
traces, reflection, etc would hide the engines implementation details)


I think that with the above, #1 makes it easy as no further changes are 
required to make that happen, they're already directly callable and #2 
jives with what *most userland programmers* would expect.


Anyone disagree?

On 10/26/2012 5:37 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the 
remaining "being debated" categories referenced in this 1.1 -> 1.2 
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests 




Some people are in favor of the internal functions being generated by 
an accessor declaration should be invisible and non-callable directly. 
Others are in favor of leaving them visible and callable.


*Type 1 ( Userland Programmer )**
*
As a userland programmer, someone who cares nothing for "how" php 
works, only how their own code works. If they define an accessor they 
expect to see an accessor, reflection should reflect that there are 
accessors and no other "methods" they did not explicitly define. If 
they were to reflect on all of the methods of their class and see a 
number of __getHours() they may be confused as to why or where this 
function came from. From their perspective, they have defined an 
accessor and "how" that accessor works on the inside is of no 
importance to them and only seeks to complicate or confuse matters 
when they are exposed to these "implementation details" of the php 
language its-self. If you tried to set a value such as $obj?abc = 1 
through an accessor which could not be set, you would probably want to 
see an error like: Warning, cannot set Class?abc, no setter defined.


*Type 2 ( Internals Programmer )**
*
As an internals programmer, you want nothing hidden from you. If an 
accessor implements special __getHours() methods to work its magic, 
then you want to see them, you want to call them directly if you so 
choose. In effect you want nothing hidden from you. In this case you 
probably don't even want Reflection to reflect accessors as anything 
different than specially formatted and called methods on the class. 
This can be understandable because you want all information available 
to you. You would probably not be confused if you wrote $obj?abc = 1 
and got back an error like "Fatal Error: Class->__setAbc() function 
does not exist.


*Unfortunately 80 to 95% of all people who use PHP are of the first 
type.**

*
Revealing these internal matters to them would only leave them 
confused, possibly frustrated and likely asking about it to the 
internals mailing list to answer (repeatedly).



Thoughts?



--
-Clint

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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Lester Caine]

Ralf Lang wrote:

Unmaintained Software will retain unfixed bugs, unfixed security
holes and ultimately break because of external changes. the mysql
extension maintainers do not want to or cannot support the extension for
much longer.


Is there anything drastic that still needs to be fixed in the current version of 
the extension? Can't we just start developing a 'legacy' build which will be 
available as an fallback and something that others can lightly maintain in terms 
of any critical security stuff? The idea of an LTS version has been continually 
shot down, but having something that can reliably run legacy code and where 
working versions of 'eol' extensions like mysql can be stored, rather than the 
vague hit and miss situation currently where we as developers have no idea what 
an ISP's setup may be using versions wise? I make no apology for repeating that 
this SHOULD have been done before PHP5.3 was pushed out and I would be 
interested to see if there IS any interest in reopening PHP5.2 as a legacy 
platform, as certainly 5.3/4 do not provide that base! At least it would provide 
a reference point to work from.


Crib sheets of information on how to move code from the legacy base to the 
current build are then easier to develop while currently if PHP5.2 code has not 
been 'updated to' 5.3, then moving it two or now three versions is even more 
painful. And we still do not have good references of how code SHOULD be built 
nowadays. Certainly my own code bases are apparently archaic but just fixing 
E_STRICT warnings does not produce clean PHP5.4 code, just bodged 5.? stuff :(


--
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] RFC: ext/mysql deprecation

[Pierre Joye]

hi Adam,


On Mon, Nov 12, 2012 at 2:00 PM, Adam Harvey  wrote:
> Hi everyone,
>
> I've written an RFC to cover deprecating ext/mysql in PHP 5.5:
> https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft
> deprecation in the documentation purely via a straw poll on Internals,
> I presume this will end up needing to go to a vote, hence the RFC.
>
> I won't rehash the background overly (there's some more detail in the
> RFC), other than to note that we've now had deprecation notices on all
> mysql_* functions in the manual for about six months and that the
> logical next step is to start generating E_DEPRECATED notices when
> users connect via mysql_connect(), mysql_pconnect() or the implicit
> ext/mysql connection routines. It's my belief that doing so will
> hasten the move of users to the more modern (and supported) APIs
> available: mysqli and PDO, and that this process will also likely
> encourage some users to switch to safer patterns such as prepared
> queries at the same time.
>
> I must apologise for the lateness of this RFC: I had hoped to do this
> some time before alpha 1, but travel and illness have taken their
> toll. Better late than never!
>
> So, please provide comments, feedback, concerns, and so on. Obviously,
> this isn't going to a vote for at least a couple of weeks, but earlier
> feedback is better.

I think there is a somehow clear consensus that E_DEPRECATED is just fine.

Discussions now are mostly about killing mysql or some ever ending
rant about notices being a breakage.

I would suggest to move to the vote phase after the one week period.

Thanks for bringing that up,

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] RFC: ext/mysql deprecation

[Ralf Lang]

>> Why again we must breaking people's working code?
> 
> Something I've been asking for years ;)
> 
> Bigger frameworks still designing for PHP5.3 is happening because 5.2
> code still works on 5.3 by hiding warnings, but fails on 5.4. They are
> trying to keep THEIR users functional in the real world, and the real
> world is dragging it's feet simply because the majority of users would
> not know what E_DEPRECATED means. "They have had plenty of time to fix
> this" assumes that the people who wrote the original code are still
> around TO fix it? I'm still finding live code that originated in PHP4
> days - using 'mysql_' - and works perfectly - on 5.2.
> I have three options now ...
> 1/ Stick with a stack that will run their code
> 2/ Tell the customers they need to repair all their code
> 3/ Charge them for the time to repair the code for them
> 

Coming from a distribution packaging background, keeping software alive
and secure is an ongoing effort. It's not buy and forget.

Scripts and frameworks need security and bug fixes, binary code needs to
be rebuilt against newer base system libraries, and as compiler versions
mature, a lot of code which previously built needs to be fixed even if
it's unchanged. There is nothing wrong with that. It's just the way it
is. Unmaintained Software will retain unfixed bugs, unfixed security
holes and ultimately break because of external changes. the mysql
extension maintainers do not want to or cannot support the extension for
much longer. It's perfectly ok for them to do so. php internals' task is
to run this through their deprecation cycle and educate anybody who is
listening how to cope with it.

-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: l...@b1-systems.de

B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg /
http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Johannes Schlüter]

On Tue, 2012-11-13 at 22:42 -0800, Stas Malyshev wrote:
> Hi!
> 
> >>   2. Mention how to turn off E_DEPRECATED warnings in the RFC?
> > 
> > Done and done. I've added a (short) workarounds section towards the
> > bottom, which can be moved up later if the RFC is accepted.
> 
> Please note currently PHP has no mechanism of turning off any warnings
> or errors. The best you can do is to cause them not be printed. However,
> any tool that intercepts error messages still sees them, they still
> consume resources when produced, still may break unit tests if you're
> not aware of them and they convert errors to failures like PHPUnit does,
> still will break any code that sets it's won error reporting if it
> doesn't remember to disable deprecated messages, etc. So adding warnings
> hurts performance and may hurt functionality even if you don't see them.

If PHPUnit breaks on E_DEPRECATED by default I would consider it broken.
(But I see your point)

johannes

-- 
Johannes Schlüter, MySQL Connectors Team, ORACLE Corporation


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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Lester Caine]

Stas Malyshev wrote:

But with a strong warning that on a later version of PHP things WILL stop
>working altogether? More often now E_DEPRECATED is already switched off simply

Why again we must breaking people's working code?


Something I've been asking for years ;)

Bigger frameworks still designing for PHP5.3 is happening because 5.2 code still 
works on 5.3 by hiding warnings, but fails on 5.4. They are trying to keep THEIR 
users functional in the real world, and the real world is dragging it's feet 
simply because the majority of users would not know what E_DEPRECATED means. 
"They have had plenty of time to fix this" assumes that the people who wrote the 
original code are still around TO fix it? I'm still finding live code that 
originated in PHP4 days - using 'mysql_' - and works perfectly - on 5.2.


I have three options now ...
1/ Stick with a stack that will run their code
2/ Tell the customers they need to repair all their code
3/ Charge them for the time to repair the code for them

Many ISP's are simply opting for 1 because 2 can't happen on many accounts, and 
there is not enough time available for 3 which most customers could not afford 
anyway.
I've been forced to move sites from their exiting hosting simply because that 
host HAS upgraded and I don't have time to fix all the problems on code for the 
customer!


FINALLY sorted why everything was broken moving from Apache2.2 to 2.4 now I have 
to work out the 'politically correct' fix for that :(


--
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] RFC: ext/mysql deprecation

[Johannes Schlüter]

On Wed, 2012-11-14 at 00:23 +0100, Ángel González wrote:
> - The extension is not broken. The problem is the bad usage.
> It can be used safely, and good developers have been doing
> so for ages, by creating php wrappers.
> In magic quotes, the work has been the opposite. The developers
> had been detecting the feature in php and *disabling* it.

ext/mysql is hard to maintain code. It is not not getting new features.
Keeping it up to date for working with new versions of libmysql or
mysqlnd versions is work, we probably could spend that time better.

> - How many hosts/ISPs have mysqli installed?
> I don't have actual numbers, but it used to be much less common
> than ext/mysql, which means that unless they those customers
> won't be able to run the applications forced to migrate to mysqli.

I have barely seen systems having ext/mysql but not mysqli.

> - A "magic porting script" has been mentioned on this thread.
> It is not on the docs, so it is really as if it didn't exist for the 99%
> of the
> population. Moreover, there is even a FAQ stating that there are no
> migration
> scripts right now:
> http://php.net/manual/en/faq.databases.php#faq.databases.mysql.deprecated
> 
> It should be linked from every mysql page.

Providing a patch to docs is relatively easy )(-> edit.php.net)
the mentioned script is a few years old, one should check and test it
before adding it to the docs, though. Maybe you can test it?

> - If you are sure your ext/mysql usage is safe, it is not possible to
> disable the warning
> for this functions but keep the other E_DEPRECATED.

If the EDEPRECATED is thrown during connect only most people won't see
it anyways. As a typical pattern looks like

   if (!@mysql_connect()) {
   log-and_print( mysql_error() );
   }

And therefore hiding raw error messages.

> - I'm quite sure that there will be a number of problems where the
> replacements have
> issues, but they are unlikely to be fixed if not forced. For instance, I
> remember a php script using mysql that from reading the code, it shouldn't be
> working but it somehow did. Completely unmaintained, of course.

You have years till the last PHP version with ext/mysql will be out of
support. Even then it is likely that one could ext/mysql still working
on newer versions of PHP (PHP barely changes core extension APIs so
people can fetch it from pecl or something, if there is a strong enough
demand we might keep aneye on it for awhile on pecl, too)


If there are real concerns about mysqli or people struggling while
migrating they can feel free to talk to us and we can assist.


johannes
-- 
Johannes Schlüter, MySQL Connectors Team, ORACLE Corporation


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