Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65526
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.185 cause and error)
Message-ID: <510A3067.2060600@lsces.co.uk>
Date: Thu, 31 Jan 2013 08:50:47 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <op.wq746rv5idpuyk@damnation.nl.lo.geleia.net>  <op.wrmidlpiidpuyk@damnation.nl.lo.geleia.net>  <debcd9bb-79f3-4b2c-aa66-9461018959c9@email.android.com>  <op.wrmkyvlwidpuyk@damnation.nl.lo.geleia.net>  <1460659e-237d-4c7c-8cfa-523ec857d646@email.android.com>  <be26f8067c25e21448eb7f3fc21809b0@mail.gmail.com>  <51074873.5090600@roojs.com> <51076233.2040507@sugarcrm.com>  <5109A834.6070503@roojs.com> <5109B421.4000805@sugarcrm.com>  <5109CC1F.3070507@roojs.com> <1359602425.11156.416.camel@inspiron>
In-Reply-To: <1359602425.11156.416.camel@inspiron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Deprecate and remove calls from incompatible context
From: lester@lsces.co.uk (Lester Caine)

Todd Ruth wrote:
> Could there be a compromise that would allow us evildoers to continue in
> our evil ways without identifying and changing every use?  Perhaps
> "implements allowStaticCallsFromIncompatibleContexts" or somesuch?  I
> can imagine replacing every "class ..." with "class ... implements ...",
> but identifying and changing every place we use an incompatible context
> will be very, very unpleasant.  We can figure out the places that are
> hit most frequently using the logs, but that isn't necessarily a
> complete list.

It's all this 'implements' and the like which is complicating things along with 
'the proper way of doing things'

The exercise that I am STILL working through is one where an objects function 
used to be used statically as well as via $this ... if $this existed use it 
otherwise generate a static result. As far as I am concerned still there was 
nothing wrong, but I've gone through the exercise and written a HECK of a lot 
more code switching a single function into three functions! A static call, a 
$this call and often a further static function that has the shared code. I 
forget now why the static call could not be used directly ... OH matched 
parameters across all classes ... the base static has a subset of the class ones.

The main point here is that there was nothing functionally wrong with the PHP5.2 
code, it had been doing it's job perfectly, leave E_STRICT off and the code 
continues to work! I don't like this comparison with E_DEPRECATED, that is a 
different concept in my mind ... E_STRICT is purely style police imposing other 
peoples style choices, so the current debate IS appropriate, and it's nice to 
hear a few more voices against some of this.

I can see that the resulting code changes improve the code, but I know I am 
still missing a lot of the 'style changes' that I SHOULD be using simply because 
of only hitting the E_STRICT warnings. It's a decent 'style' scanner that is 
needed rather than these odd warnings in the core code :( To some extent 
phpdocumenter helps here as the generated documents do flag up some of what as 
been missed but certainly not all.

-- 
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