[TYPO3-core] Adding visibility to methods and variables within t3lib_tcemain?

[Roland]

unfortunatelly TYPO3 4.7 does not have LTS. if it would have LTS, breaking
backward compatibility in TYPO3 6.0 would not be that much of a problem i
think.

kind regards.

roland



Steffen Gebert <steffen.gebert at typo3.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> We have a major release and we should take the chance to break
> backwards-compatibility, when deprecation is hard to achieve.
> 
> Kind regards
> Steffen
> 
> - -- 
> Steffen Gebert
> TYPO3 v4 Core Team Member
> TYPO3 Server Administration Team Member
> 
> TYPO3 .... inspiring people to share!
> Get involved: http://typo3.org
> 
> I work for TYPO3 solely in my spare time. If you think that
> my work helps you running your business, you are invited to
> send me a donation via PayPal to this email address. Thanks
> 
> On 12.06.12 10:23, Tolleiv Nietsch wrote:
>> Hi,
>> 
>> I recently made two requests to add visibility information for all
>> t3lib_tcemain methods and member variables [1], [2]. Christian brought
>> up certain concerns that this should be discussed with the list before
>> it's merged. Therefore I'll give you a short explanation what my
>> motivation was to make these requests and afterwards you're invited to
>> comment on it ;)
>> 
>> From my understanding especially t3lib_tcemain acts as public API to
>> work with records in TYPO3 (even if that changed a bit with extbase).
>> Therefore t3lib_tcemain should have a clear and clean API and that
>> should focus on the purpose of that class.
>> 
>> From what I see at the moment the API is cluttered and every attempt to
>> refactor or clean it up can't be done without a preceding deprecation
>> step 6 months before the actual refactoring. I guess you'll figure
>> yourself why this is an issue.
>> 
>> For the two requests I figured out which of the t3lib_tcemain members
>> and methods are currently used from the outside and then protected all
>> others. What I see as the result is that some functional blocks (e.g.
>> all the checkValue_* stuff) could now be moved out into separate
>> classes, other methods could be turned to be "protected" with the normal
>> deprecation procedure and some other known-to-be-public methods could be
>> treated as such and receive some more attention in regards of
>> input-validation etc.
>> 
>> Still I agree with Christian, proceeding with the requests is not a
>> small step but I think that 6.0 also enables us to make these (slightly
>> breaking) changes without complex deprecation methodology.
>> 
>> Cheers,
>> Tolleiv
>> 
>> [1] http://review.typo3.org/11624
>> [2] http://review.typo3.org/11635
>> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJP22gVAAoJEIskG/rSlyw4beQH/1oxJ6f85M0PIhGid+Q1EHBj
> WCFXQ/XWUY4hhV7uKEc36z1dzRs0Z3k4tBihnbCUr4RpjMTj77oKT4Vf+iXKZvqX
> 56nPMmDYBF2hF0p8N8yd8mMBXsYw+5DbUcIPIRpfEILvuhLVL23EC7MeMEfl1Rbw
> 3eOALLpS6EkHmaqGaNIf56gv2lfJV/ECGvOTEgA1apfo9cdFroPeE0JUedXWBGT1
> pKqlFiHvGxl8+Q3xqksQdJkrFfhXC5YpFU+z8AI5CkgkjdQCgzgHck+AcF8VdAac
> 1LUoDlcDcMqBU+L93dr9UA2FwC8DT1k6ML/BHJ4U1B96EO2M+/m5+tZ9fTQOodE=
> =F/ke
> -----END PGP SIGNATURE-----