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

[Marcos Douglas]

On Fri, Oct 7, 2016 at 11:46 AM, stdreamer <stdreamer at freemail.gr> wrote:
> 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?

Of course! As I explained before.

> 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?

The problem is: The user (programmer) needs to know (previously) if
such classes can or not be used as a contained object!

>> 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),

We don't need "clean up properly" instances that is interface-based.
If this solve the problem for contained objects, I'll do it!
BUT, if I do this I can forget all about  TContainedObject or
TAggregatedObject? If I can't, this not make sense.

>... 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?

"...to a language feature that has nothing to do with it."
Your opinion.

I've been using COM Interfaces (ref-counting) for years without
problems of memory leaks.
I just want to use the feature "delegation". That's it. But the design
of this solution looks wrong. Not only in FPC, but Delphi too — as
said Graeme.
The documentation recommends nothing about TContainedObject or
TAggregatedObject on topic about Delegates.

IMHO this is a problem. You guess not, but you just know a workaround.

There is a design problem. Maybe there is no solution. Maybe is so
hard to fix that don't worth. I don't know... but there is a problem.
It's a fact.

>> 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.

So, if I understood right, you saying that:
If I have a function that expects an IStream interface as argument, I
can't pass any class that implements that interface BEFORE see which
hierarchy it belongs? If I will can use as "contained", "aggregated"
or just "stand alone"?

> 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.

So, I can change the hierarchy of my classes and break the whole project?
Is it correct and makes sense for you?
I truly know that is not about encapsulation or about object-oriented
programming.

> 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.

That is a good idea.

If is possible. If doesn't have any "compiler magic" inside this
classes, I will do it.
Better. I will copy the implementation of these classes to create my
own implementations.

> I'm against adding that kind of functionality to TContainedObject as
> it is outside of its designed goal.

I agree...

> If a new object adds more value or more bloat to the library is up to the
> maintainers to decide.

...but IMHO, it would be a better design if these classes do not exist
for this purpose.

Best regards,
Marcos Douglas