On 07/10/2016 18:33 μμ, Marcos Douglas wrote:
The problem is: The user (programmer) needs to know (previously) if
such classes can or not be used as a contained object!
True then again that is true for all objects not only interfaces. You
need to understand what they address how they address it and what are
their short comings to use them to their full extend.
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.
Well this makes me think that you do not understand the difference
between heap based and stack based variables. You do understand that a
variable on the heap never goes out of scope, which makes automatically
decreasing the reference counter impossible, right? You have to nil it
manually and this is true in C++ as well.
"...to a language feature that has nothing to do with it."
Your opinion.
I wish.
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.
of course not, contained objects is one solution it can be reversed as
well ee the contained object is in fact the object that used the
delegate and depending on the design it can be passed as parameter in
the constructor or changed through the property to something else that
is not contained at all. It so happens that you are using the contained
object logic.
To be clear I have no objection in mentioning the pitfalls in the
documentation and show the tcontainedobject as a possible solution to
the problem.
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.
I disagree the use of "fact" in this context is wrong but hey what ever
floats your boat.
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"?
That is a use case and no I never said that your use cases are wrong
invalid or improper.
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.
I have to question a design that changing a single inheritance breaks
the library. If this is such a big problem then don't change your
hierarchy make sure that you are properly setting all interfaces in the
heap to nil when you are finished using them and forget about everything
else.
Or go the opposite route create an IContained interface that
encapsulates the code in TContainedObject and tell your team that you
can use any class that implements IContained as a delegate.
There are a lot of designs to pick from and every one has its pros and
cons pick one that fits in your design.
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.
That's the spirit use the library to your advantage and if you have the
time, inclination and will, post a proposition for a new class giving
the use cases it addresses.
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.
Well I learned from them, used them verbatim and customized them to my
use cases, they are an asset in the library a reference point and they
are a good reference too, so I have to disagree I guess.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
