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

[Tolleiv Nietsch]

Hi,

seems even if it's hard, it's time to draw a conclusion here.

What I understood from your mails is that the way I proposed is 
obviously the wrong one, because most people preferred the "regular" 
deprecation cycle for these changes. Although there's no technical 
solution which everyone agreed on, everything which appears to be public 
now, should not be turned to be protected without deprecation.

I hope that summed it up right. I will abandon the two review requests 
and leave t3lib_tcemain untouched. I've at least one followup question 
which I'll bring up in a new thread.

Cheers,
Tolleiv

Tolleiv Nietsch schrieb:
> 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
>

-- 
Tolleiv Nietsch
TYPO3 Core Developer


TYPO3 .... inspiring people to share!
Get involved: typo3.org