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
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
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
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,
hi Adam,
On Mon, Nov 12, 2012 at 2:00 PM, Adam Harvey ahar...@php.net 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
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
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
@ 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
On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest cpri...@zerocue.com 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
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
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
On Wednesday 14 November 2012 16:35:31 Nikita Popov wrote:
On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest cpri...@zerocue.com 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
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
On 15 November 2012 08:36, Devis Lucato de...@lucato.it 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
*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
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
16 matches
Mail list logo
