On Fri, Oct 7, 2016 at 11:46 AM, stdreamer <stdrea...@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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
