[fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)

[stdreamer]

On 07/10/2016 16:12 μμ, Marcos Douglas wrote:
> The team shouldn't know about the hierarchy; about how was implemented
> these classes.
> They can use TDataStream directly or as a contained object.
> But as I understood, we need to use TContainedObject or
> TAggregatedObject only in these "special cases"
You are correct the TContainedObject can only be used with a root 
object, now what? Is this a block for you?

It is not the library's responsibility to solve your problems only to 
assist. TContainedObject is a basic solution which is generic enough to 
accommodate 90% (assumed number just to emphasize its usefulness) of the 
use cases.
Now why is your use case special enough to be included in the library it 
self?

> I didn't test yet. I will. But if I'm right, ie, if TDataStream is
> inherited from TContainedObject and, because that, I can not use
> TDataStream as a simple instance, without a "root" object... well,
> this design is wrong.

well let me see....
You failed to clean up properly after your code (a simple fValue := nil 
in TMyApp.Destroy method should solve all your problems), you did not 
knew the basic mechanisms provided for the exact problem you are having 
and you attached your design sort comings to a language feature that has 
nothing to do with it. All in all, you have failed to do your homework. 
I should listen to your opinion about design ..... why exactly?

> If somebody says: "You should know these classes..." or "you should
> know what you're doing..."
> I will answer: this is not about OOP, just procedural. OOP is about
> encapsulation. If I need to see the class' code, this means that it
> was not well done.
>
No! Any object solves a single problem. If it does not fit in your own 
design then you either have the wrong design or you need to customize 
the object to include your use case. In both cases you need to read up 
and understand which use cases is solving, how it does it and how you 
can extend it to support your own use cases. It is not responsible to 
accommodate your assumptions.

Can things get better? Sure every change no matter of its size, moves 
the library forward but if that change is appropriate for the library 
can only be decided by the library maintainers and you (or me for that 
matter) crying wolf does not help.

For me extending the TContainedObject to support both contained and 
stand alone use is trivial I bet you can do it as well now that you know 
where to look. I'm against adding that kind of functionality to 
TContainedObject as it is outside of its designed goal.
If a new object adds more value or more bloat to the library is up to 
the maintainers to decide.