[TYPO3-dev] Extensions need update for 4.3!

[Ernesto Baschny [cron IT]]

Dmitry Dulepov wrote: on 09.10.2008 23:04:

> Ernesto Baschny [cron IT] wrote:
>> Well, NULL wasn't wrong until probably 4.3, those extensions were not
>> "broken" before, which is why I don't think they should "brake" after
>> the 4.3 upgrade.
> 
> I think it depends on the view. Does saying "array" mean that null is
> right? To me it looks wrong.

Yes, good notice. It looks wrong to you, but nobody ever stated it was
wrong. We could change it now so it is wrong, but I see no apparent
reason to do so.

Even java, which is known for its strong enforcement of types works like
that:

class HintApp {
    public static void main(String[] args) {
      HintApp.test1(null);
      HintApp.test2(null);
    }
    public static void test1(String[] args) {
      System.out.println("Hello 1");
    }
    public static void test2(HintApp test) {
      System.out.println("Hello 2");
    }
}

Works like a charm. I passed "null" to a method expecting an array of
string and to another method expecting a class.

But I agree that in our "regular" methods (internally used, new API
methods, etc), we should sufficiently enforce the array type and not
allow NULL, because it spares us a check in the method.

> Well, to me it does not look like a clean solution, thatš all :( It
> certainly solves the problem but it is not clean. I am not saying I am
> completely against this idea but I truly want developers to write better
> code.

Me too. But to me also the balance is important. My main concearn isn't
to educate developers.

>> TYPO3 has always claimed for high backwards compatibility, which is why
>> many people love it so much. Lately the trend has been to "lets change
>> it because it looks nicer" and turning down "mere users" which cannot
>> upgrade their installations because they run some extension that does it
>> "old school".

> Well, you know, I am the one who always asks about compatibility and
> requires that it is observed ;) But this particular case is not only
> about compatibility but also about responsibility of the developer and
> quality of the code. This is how I see it. But this is my personal
> opinion, I do not say I am absolutely right :) You know, I am pedantic
> in many things ;)

Your argument could be used on every other backwards compatibility
issue. We are always making our code "better", but we have to keep
certain aspects working, even if they are ugly or bad. "content
(default)" is still being "maintained", tons of global variables are
accessible and changeable for every extension. If we follow your advice,
we could get rid of all global variables, rethink the namespace and then
argue: well, this will probably break all extensions, but we have to do
it to educate the developers not to access those stuff that were never
meant to be accessed.

We don't usually work that way. And I know that you are concearned about
it, this is probably why I wondered about your conclusions. :)

Thinking about it, I am not sure how widespread the problem would be.
Quickly scanning through some extensions, I haven't found any which did
it wrong. Steffen, could you give us some examples where you found it?
You said "many" in your initiation of the thread.

Cheers,
Ernesto