Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61910
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.193 as permitted sender)
Message-ID: <5018E16C.8020703@sugarcrm.com>
Date: Wed, 01 Aug 2012 00:57:32 -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> <5018D80D.7020502@sugarcrm.com> <5018DDD4.7010608@lsces.co.uk>
In-Reply-To: <5018DDD4.7010608@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!

> Only with short tags on ... 5.4 has detached it from that, but 5.3 still 
> switches it off by default, and convincing ISP to switch short tags on again is 
> a lost cause :( Fixing it in PHP5.3 was rejected :(

Errm... So you are complaining we're not going back in time now and make
different decision about PHP 5.3 that was made years ago? Or what is
your point exactly?

> Fine, so I just add 'static' rework all the code, and fix the error, but I think 
> I should also be adding public as well? It's not needed to clear the warning, 

If your functions are public, I'd recommend adding public. However, as
the same manual states, public is optional for BC reasons and if access
is omitted, public is assumed. Same manual, same page, one paragraph above:

For compatibility with PHP 4, if no visibility declaration is used, then
the property or method will be treated as if it was declared as public.

> mind so much some of the rework, but I've no confidence that I will not be doing 
> this exercise again next year - on the same code :(

If you want somebody to assure you that the code that nobody except you
have seen would not contain any problems after you fix some of the
problems you have now but nobody except you knows about - then I'm
afraid it's not something that anybody here is able to promise you. If
you have some specific proposal - let's hear it. Otherwise I'd recommend
following current best practices for writing good PHP code - e.g. what
described in the manual and many framework style guides, etc., don't use
any "clever" tricks that abuse PHP constructs for what they weren't
meant to do - and you have reasonable assurance it will keep working fine.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227