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

Graeme Geldenhuys graemeg.lists at gmail.com
Thu May 20 10:09:27 CEST 2010

Matt Emson het geskryf:
> Having used it a lot recently, I'd prefer MVC to be used with in a  
> class library.

MVC often uses Observer! Model-GUI-Mediator (MGM) that I implemented in
tiOPF and use daily in our current software is very similar to MVC without
the need of creating descendant "view" components. MGM is a combined effort
of Observer and Mediator.

> A Subscription mechanism is more powerful. Look at the MUSCLE C++  
> framework.

I don't know the Subscription mechanism using in Muscle C++, but from the
name alone, it sounds exactly like what Observer does. Other
components/objects subscribe to some other class, so that it can be
notified of any changes. We would like this subscription idea in the base
classes because they will be incredibly useful to many - and the Observer
implementation will do just that.

> Iterator I use every day!!

Same here, and Iterator is the heart of tiOPF. I abandoned the proposal to
include Iterator in some of the base classes (like what Java has) simply
because I could see many argue the same thing as we are arguing now. At
least for the Iterator I found an external solution to the problem, so I
can now iterate any of the base classes with easy.

Unfortunately for the subscription/observer/observable functionality, there
is no external solution - hence our proposal that the base classes get the
functionality directly. If there was an alternative solution, Michael and I
would already have been using it - instead of arguing the point here.

> As Marco said - the underlying framework is fundamentally flawed. You  
> want to patch it. You need to redesign it. You are incredibly short  
> sighted here. Think outside of the box.

Yeah well, redesigning the RTL, FCL, LCL is not an option either. It will
take the next 10 years to implement; you will loose all compatibility with
Delphi and existing code....all because you only wanted to add one rather
simple feature. Letting the current code evolve (like all software does) is
a much better and simpler solution.

> Talk is cheap. I'm not using pascal enough to justify coding. But if I  
> was doing this, I'd start again, as Marco suggests. 

Yes, and I have bills to pay and no time to waist with such stupid ideas. I
code in Object Pascal for a living. Just because there is a problem (or
missing feature) in the underlying framework code, doesn't mean it must be
rewritten from scratch! Evolving code and Refactoring are common methods of
improving EXISTING code.

  - Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal

More information about the fpc-devel mailing list