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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
