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 becaus
*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
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 li
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 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
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 e
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_*
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 m
@ 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 v
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
trac
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
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 pres
>> 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 w
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 currentl
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 desi
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
16 matches
Mail list logo
