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

[Steffen Gebert]

-----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-----