Ryan Joseph via fpc-pascal wrote:
I guess I'm not seeing the design pattern which they was invented for and I've
never come across it in my own work. Not against the idea in any way however.
My mind went in the same direction as Adriaan's did when I saw "implements" I
thought that one class could be built from many smaller classes but share the same
namespace (like in multiple inheritance or entity/component designs). If a class
implements an interface via a delegate then I would expect this to function the same as
inheritance, i.e. the namespaces are merged and share functions. Doesn't that make sense?
Maybe what I mean to say is that there's a need for a delegation syntax that functions like multiple inheritance and avoids the traps of deeply nested single inheritance hierarchies. Does anyone else agree?
Compare this with relational databases where the columns of related, say "delegate", tables can be
put side-to-side with columns of the main table in so-called database views
<https://en.wikipedia.org/wiki/View_(SQL)>.
I have always wondered why hierarchies in object-oriented programming are idolized, where in the
database world hierarchical databases are something of the past and everything is relational there
now <https://en.wikipedia.org/wiki/Relational_database>.
Regards,
Adriaan van Os
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
