Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61907
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.123 as permitted sender)
Message-ID: <5018D80D.7020502@sugarcrm.com>
Date: Wed, 01 Aug 2012 00:17:33 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Lester Caine <lester@lsces.co.uk>
CC: PHP internals <internals@lists.php.net>
References: <50163FAD.4020004@lsces.co.uk> <5016A5A8.50506@lerdorf.com> <5018CA7E.5070802@lsces.co.uk> <5018CC83.4030002@sugarcrm.com> <5018D2D1.2040004@lsces.co.uk>
In-Reply-To: <5018D2D1.2040004@lsces.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Bringing users along ...
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> PEAR and PECL that work with PHP5.4 out of the box?
> At least the core of PEAR that does not throw strict warnings from a stock 
> install of PHP5.4 as E_STRICT is on.

For PEAR is think it is a wrong list, as for PECL most extensions are
maintained by their maintainers, and internals specifically works only
on the core.

> I think that this is the problem here. "fixing bad code" is simply not a 
> statement that I recognise! I am not fixing bad code, I am re-writing much of it 
> simply because the style is no longer acceptable, or somebody changed a default 

You are trying to reframe the same meaning with different words, but the
meaning does not change - the code that is no longer acceptable in 5.4
is not acceptable for a reason. Usually the reason is that the code is
broken or using PHP in a wrong way - such as silently converting nulls
to objects, strings to arrays, arrays to strings, etc.

> setting without considering the consequences ( <?= not working in PHP5.3 is 
> STILL biting as ISP are only upgrading to PHP5.3! )

Err, I'm not sure what you mean - <?= certainly works in 5.3.

> I still have not had a proper answer to a question I repeatedly ask. "Please can 
> we have some tutorials on how 'strict' styling should be used?" I'm fixing the 
> warnings created but I still do not fully understand what I am fixing. The main 

I, for one, do not understand what you are asking. If somebody could
explain it would be nice. "Strict" warnings are issued when your code is
doing something that the designers of the engine consider a bad idea,
which in vast majority of cases means a bug.

> rework area has been not being able to use '$this' in static functions, even if 
> the function checks $this and defaults to the static code internally. Adding 

Good example. "static" function is called static for a reason, and the
reason is it does not belong to an object but to a class, thus it can
not and should not have $this. Code that uses $this in a static function
is thus broken and needs to be fixed. In overwhelming majority of the
code this is a bug. If some code used it as feature, it was a bad idea,
and the time of this bad idea is gone now.

> 'public/private/protected/static/self ...' and using them in the right places is 
> well documented in bits and pieces, but there is no general 'how to' put the 
> whole together? I suppose someone will want to add traits and the rest to that,

How to put what together? The manual page for static states explicitly:

Because static methods are callable without an instance of the object
created, the pseudo-variable $this is not available inside the method
declared as static.

What other howto is needed for this?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227