[TYPO3-core] QueryInterface-compat for CMS 6.1 and 6.2?

[Stefan Neufeind]

On 04/10/2014 08:58 AM, Xavier Perseguers wrote:
> Hi,
> 
>> The QueryInterface (Extbase Persistence) changed between 6.1 and 6.2.
>> In 6.1 one param is given just with an annotation for an "object" in
>> phpdoc, 6.2 now mentions a param of a certain class.
> 
> The interface was actually cleaned up a lot in the last days before
> release of 6.2 because it was actually a pretty mess with partially
> wrong annotations or hints.
> 
> Though nothing against the work that was done in Extbase before of
> course, but we decided to get a clean base for the new LTS
> 
>> Do I guess right that it's not possible (at least not without a hack) to
>> have an implementation that works with both interfaces?
> 
> I just tested this:

[...]

> <?php
> 
> interface A_61 {
>         public function foo($mydate);
> }
> 
> interface A_62 {
>         public function foo(DateTime $mydate);
> }
> 
> class B_61 implements A_61 {
>         public function foo($mydate) { return 'ok'; }
> }
> 
> class B_62 implements A_62 {
>         public function foo($mydate) { return 'ok'; }
> }
> 
> class C_61 implements A_61 {
>         public function foo(DateTime $mydate) { return 'ok'; }
> }
> 
> class C_62 implements A_62 {
>         public function foo(DateTime $mydate) { return 'ok'; }
> }
> 
> 
> when I run it, I get
> 
> Fatal error: Declaration of B_62::foo() must be compatible with that of
> A_62::foo()
> 
> So the C_* implementations seem to be fine for everyone, both the 6.1
> world and the new, strict 6.2 world.

Hi,

thanks for putting these examples together.
I've run them on PHP 5.3.3 and 5.5.11. After commenting out the
B_62-case which of course leads to problems I was astonished to see that
C_61 also fails for me.

Declaration of C_61::foo() must be compatible with A_61::foo($mydate)

So that was the problem I experienced. Extending your class with an
object-type (for 6.2) that leads to problems when trying to use it with
the old interface in 6.1.

Any good solution - expect one "hacked" one?
Hack: We could create a php-file so the autoloader knows where to
search, put a version-check in there and require_once one or the other
class-file. Would work ... but imho no option :-)


Regards,
 Stefan