[lazarus] Remove interface class?

[Florian Klaempfl]

Marc Weustink wrote:
> + From: Micha Nelissen [mailto:micha at neli.hopto.org]
> + Sent: donderdag 18 december 2003 10:00
> +
> + Hi,
> +
> + As the code is, currently, we can remove the interface class.
> + The global interface functions will stay and be pointers and
> + the interfacebase will implement them as it does now. The
> + platform interfaces can rewrite the functions as needed, and
> + the private variables can be global variables private to the
> + unit (as there is only one instance of the interface
> + class). Advantages:
> +
> + 1) possibly remove IF_BASE_MEMBER stuff because only one global
> + declaration of each interface function
> + 2) speedup and code reduction, because the self pointer doesn't have to
> + be passed anymore.
> +
> + What do you think?
> 
> When implementing parts of the GTKObject I was thinking several times of
> this. If you compare a unit to a single instance of an object then there
> aren't mucht differences (at first sight)
> 
> Sure we can get rid of all wrappers and objects by declaring all
> functions/procedures as variables with function/procedure pointers.
> Then for every function we need to declare a function/procedural type.
> 
> Now some functions are implemented by default in the base class and if the
> interface had a better implementation it should be overridden. So if we
> use function pointers the interface initialisation should take this into
> account. And also when some functions need to call "inherited".
> In fact, this way, you are implementing your own VMT.
> 
> 
> Indeed this way you can get rid of some ifdefs (you can also get rid of
> them by introducing another .inc file. the reason why the ifdefs are used
> is 1. lazynes on my side, 2. force that both headers are the same)
> 
> Also indeed you can reduce some calls, since you don't need the wrapper
> functions anymore.
> 
> 
> What would I think... It has some advantages, but I don't expect that
> there is much speed to gain. (passing self for instance is peanuts
> compared to the actual function implementation)
> One major thing I see is the awful lot of work of rewriting things.
> Besides that, I don't think that something as gtkobject.inc would become
> much easier to understand.

We did the same decision for FPC: the code generator in FPC is also OOP 
(base class contains stuff used by all CPUs and a child class implements 
the CPU specific stuff) thought it would be possible to do it via units 
because never one executable supports different CPUs. However, we 
decided to use the OOP approach because it's less error prone.