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

[Marco van de Voort]

In our previous episode, Matt Emson said:

> Patterns take extreme discipline because unless you adhere to them, your 
> code gets incredibly convoluted. Been there, seen it.

When applying any algorithm or technique, you need to see if it fits, and if
it is no overkill, patterns are no different there.

When I first came into contact with patterns I really liked the idea. The
authors just noted they wanted to write down the commonly used patterns, to
create a common jargon, and a discussion of basic pro and con's.

I'm not anti-pattern, and it is not patterns that are under discussion here.
Neither is that there are a lot of clueless pattern followers that try to
stuff 6 patterns  into what is basically a for i:integer= loop and creating
an object for each bit of the integer, because they are so cool and modern.

The point is the question if a given, existing framework should be patched on
such a deep and crucial level with support for a new concept, just because
somebody wants to use the pattern in some package, and he needs a hook in
the framework.

This really sets a dangerous precedent IMHO, and it is only a matter of time
the next proposal pops up. 

Moreover it sets a precendent that suggestions like this that are suggested
by users are rejected, but if two FPC devels have an itch, it is forced in.

It is one of the perils of open source I guess. Because the source is
clearly open, every itch must be fixed in the main source and framework.

That's also why I don't understand why Graeme is so angry. I give proposals
from FPC devels the same scrutiny and criticism, on the same basis (delphi
compat and not part of commonly shared direction) as his proposals. In my
book that is what fairness is about.