[Typo3-dev] re-engineering the form content type

[dan frost]

> 
> Though I'd prefer to create *new* APIs rather than changing old ones. The old stuff could be turned into empty shells that only wrap calls to the new API.

I have a feeling - partly because I've being trying to do this with 
TypoScript and the extension class - that creating wrappers would be a 
horrible job.

A better plan would/might be to have new and old API for some time. Make 
sure that use of new and old API is easy to detect (e.g. by grep'ing for 
them in extensions) so you can tell where a backwards compatibility 
problem lies.

Then, as Typo3 develops (over the next year) use the new, more tidy APIs.

> Anyway I was referring to backward compatibility for users not developers.. Removing features of a content type will break existing sites. Removing APIs might break them as well...

Even so, I think that working on a really tidy, much more modular API 
system would be so big a job that a phased implementation would be best.

As an example - say we went from using mysql(...) to dbal(..), which 
could be a database-abstract-function. Finding its use in extensions, 
and the core is easy, and replacing it is quite simple. BUT, while both 
functions are there (during the phased implementation) both can be used.

It's a less than perfect solution, but open source software has a funny 
backward-compatibility thing in a way - it's sort backward-ish 
compatibly...kinda..!


Anyway, I think that we need to divide the so-called API into 
"libraries" (e.g. _div) and the "real API" (e.g. any link-building 
functions etc). (I take API=application programming interface, btw)

dan