[TYPO3-core] CGL violations "unused parameters"

[Ernesto Baschny [cron IT]]

Roland schrieb am 23.10.2012 21:35:

> thanks for your answers.
> 
> "Ernesto Baschny [cron IT]" <ernst at cron-it.de> wrote:
> 
>> * backwards compatible API
> 
> is there some kind of deprecation strategy for these cases or will these 
> arameters stay there forever?

Yes, there is a strategy. If someone wants to remove a parameter from a
public TYPO3 CMS API, it has to be:

0) Version now: Accept all parameters

1) Next version and Next version + 1: Still accept all parameters, but
call t3lib_div::deprecationLog (AKA
"TYPO3\CMS\Core\Utility\GeneralUtility::deprecationLog").

2) Remove the parameters

Thus the deprecation has to pass two minor versions with logging the
future deprecation before being actually removed.

Often instead of simply removing unused parameters, it makes sense to
refactor or clean up the whole component in question. In this case, make
sure the old API still works and act as a wrapper to the new API while
calling deprecationLog for two versions.

> how can someone with not that much experience with TYPO3 core see that
> there is some backwards compatibility issues?

If the class is public and the method is public, it is *always* a
potential compatibility issue! This method might be used by some foreign
code (extensions) which will break if you remove the parameter (a PHP
Fatal error).

>> * is used in some XCLASSed code
> 
> how do you see if this is the case?

You have to check every single extension out in the wild. Consider that
not only public extensions in TER might do a XCLASS on a TYPO3 CMS Core
class, but also "private" custom extensions created for some customer.
So we cannot know which classes are XCLASSEd, but can assume that all
public classes *can* potentially have some XCLASSing.

>> * is used by a subclass
> 
> i see.
> 
>> * in case of stdWrap et all, it's the TypoScript API that mandates those
>> two parameters
> 
> is there a document which explains this process? i am really interested in
> all that stuff.

I don't think there is a document other than the code itself. :) stdWrap
in particular is implemented in
TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer.

>> * etc...
>>
>> So I would rather disable this complete rule to get rid of the annoying
>> messages instead of "working through" them all, which seems to be a very
>> useless waste of resources.
> 
> i understand your argument and will therefore not start to fix those CGL
> violations as long as nobody else comes up with better arguments. ;-)
> 
> thanks once again for your insights.

Your welcome!

Cheers,
Ernesto