On Fri, Oct 7, 2016 at 8:29 AM, stdreamer <stdrea...@freemail.gr> wrote: > No! Delegation is a mechanism, when used, you have to know exactly how it > works.
The "mechanism" here is about using [implements]. We have to know what is the sintaxe: - declare a property - use [implements] keyword - could be a class or interface - and so on. The user (programmer) that consumes these classes as a contained objects, should't know NOTHING about their hierarchies! > Delegation is only used to minimize code instead of writing a bunch > of procedures that call the contained object's methods. That's it and > nothing more. And this is great! As I know, only Object Pascal have this feature so, let's use it. > [...] > > The point is that you are trying to equate delegation with contained > objects/interfaces and that is not what delegates are about. Delegation has > nothing to do with the underlined mechanism you choose to use. > > Having said that, I have to agree with you that contained objects are the > most common supporting mechanism for a delegation and probably the most > logical to use. Delegates is about: pass the work for another. That's it. I can do that using only classical object composition. But Object Pascal have this cool feature that I can write less and the design is really good. So, I would like to use it. But if I need to know everty implementation for all my classes, to know if I can or not use as a "contained" or "aggregate" object... this is wrong. > As I said I do not see a rabbit hole that it was created by the compiler or > the language nor I think that the compiler should constrain you to one > mechanism. Really? Best regards, Marcos Douglas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
