[TYPO3-50-general] Feature request: Running different versions of a class in parallel

[Ernesto Baschny [cron IT]]

Elmar Hinz wrote: on 11.10.2007 08:30:

> I want to come up with a feature request for v5. Maybe it's already planned,
> maybe it's an inbuild feature of PHP6.
> 
> Today one of the big issues with TYPO3 is backward compatibility. Once a
> class has an API and a behaviour, you can't simply optimize it, because  of
> the dependent classes. You can extend it, but you can't freely change it.

The idea of having a clear interface is exactly that you are able to
optimize the "inner workings". You just don't change the interface.

> I would find it extremely useful, if I could say, which version of a class
> or component I want to use. I would say that my current version of
> component X requires version 1.x.x - 1.9.x. 
> 
> The mechanism Robert designs for aspect orientation already manipulates the
> code. It should be possible in the same step to rename classes to respect
> the version of a component. For example:
> 
>  T3_MyClass could become T3_MyClass_1_16_2
> 
> Certainly you never hardcode a call to T3_MyClass_1_16_2. That would be the
> component managers job. You simply write T3_MyClass and set the required
> version in ext_emconf.php or whereever the dependency is defined.

By having a clearly layered API with meaningful interfaces we will be
able to provide backwards compatibilty much easier than it is today,
where with XCLASS you never really know who might do what with TYPO3 core.

About versions of interfaces in general:

The interfaces should of course have a clear and standarized versioning
scheme, so that the core API will be able to provide each extension with
proper implementations. So extensions can clearly depend on a certain
interface implementation (>1.16). I am almost certain that this is being
considered, although I haven't looked it up. Maybe Robert can give us
the information.

The Gallery2 project solved that very well with versioned interfaces.
There are minor version numbers (which is always backwards compatible)
and major version numbers (where "major" changes are allowed,
potentially breaking backwards compatibility). Currently all interfaces
in G2 are still at 1.0, so even after several years, they remained
constant, which probably tells us that well thought interfaces don't
need to change that often over time.

There is a "core versioning" where the complete core API version itself
(as it is always shipped "together") and there are interfaces provided
by modules (e.g. a SearchInterface, CustomFieldInterface, etc) which
each have its own versioning so that other modules can depend on that.
The factory that find modules that implement a specific implementation
will then be able to decide if the request can be fulfilled (you might
even have your extension provide multiple interface implemnetations, if
you want to provide backwards compatibility).


Cheers,
Ernesto