[fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

[Inoussa OUEDRAOGO]

2010/5/19 Graeme Geldenhuys <graemeg.lists at gmail.com>:
> On 19/05/2010, Inoussa OUEDRAOGO  wrote:
>>
>> Agreed. This mechanism exists in Delphi and is called "class helper",
>>  see http://docwiki.embarcadero.com/RADStudio/en/Class_and_Record_Helpers
>
> Ah yes, the famous "class helper" which makes designing a class
> structure way more complex because their is no real structure|design -
> lets just slap something on the side with a big band-aid.
>
> Oh and did you know about this neat little gem of "class helper" -
> probably the single biggest reason I can't see a use for class helpers
> at all.
>
> -----------------------------
> "The biggest problem with class helpers, from the p.o.v of using them
> in your own applications, is the fact that only ONE class helper for a
> given class may be in scope at any time." ... "That is, if you have
> two helpers in scope, only ONE will be recognized by the compiler.
> -----------------------------

This is the Delphi implementation limitation : _why_ should FPC
implement such limitation ?
Even in the case of (questionable)Delphi compatibility this limitation
may be activated in Delphi mode.

> So how does this help use solve the Observer problem? It doesn't.
> Maybe the code we used already bolted on some class helper which now
> makes all other extensibility impossible. Yeah what a wonderful way to
> extend classes - NOT! Interface delegation is a better design than
> class helpers. At least interface delegation doesn't limit you to a
> single feature.

Again, _why_ should FPC implement such limitation ?

> Sorry but class helpers are probably the worst "feature" [if you can
> call it that] for the Object Pascal language that Borland could come
> up with.

That is your opinion. Mine is that properly implemented, Class Helper
as a _class extension mechanism_ is
a very powerfull tool; Change the name if you want, consider the
concept, not the name please.

-- 
Inoussa O.