Edwin Yip

I'm no expert in the crypto field, how's the SynECC unit? https://github.com/synopse/mORMot/blob/master/SynEcc.pas

I'm not sure how many of you are like me, use implementation (class) inheritance (not interface inheritance, this one is OK) without too much thinking, with the intention of primarily for code reuse. Inheritance for extension is Ok, but for code reuse? Maybe not that good. Although I have achieved code reuse with class inheritance, but from time to time I feel unwanted class coupling were introduced too. It doesn't sound right and today I have spend many hours reading through aquite amount of discussions through stackoverflow, StackExchance, wikipedia, and so on, many articles seem to prove my feeling, for example: https://codeburst.io/inheritance-is-evil-stop-using-it-6c4f1caf5117 (especially this one) https://www.artima.com/lejava/articles/designprinciples4.html https://softwareengineering.stackexchange.com/a/65180/37358 Update 1: Let me quote from StackExchange user Stephen Bailey which is really well said: My conclusion === If it's only about code resue, most of the case we should consider use composition instead of implementation inheritance, like assembling a car with various more fine-grained, more manageable components. What do you think?

GExperts. Once installed you'll see the Component to Code menu item when you right click on any components on a form at design time.

@Stefan Glienke Even due to the lack of interface issue historically, the RTL/VCL is ok, because: It's designed by talented people so the class hierarchy is well designed, and it's well documented. We usually only use them from an external perspective and don't need to think about their internal relations. In case of designing our program, we do. We couldn't change that fact :) Interface is the BEST, but the 'composition over inheritance' approach still apply even if the language has no interface support. For example, let's say we need a class to perform FTP upload, we have two options: Inheritance - inherit from TIdFTP (in case of using Indy). Composition - create a new TFtpUpload class and use a TIdFTP object inside. With composition, the second approach, we'll gain the following benefits, as concluded by Nicolò Pignatelli: isolated, side effect free code units; injecting interfaces only as dependencies will remove every nasty side effect around the code you are working on; changing an interface implementation won’t affect other concrete classes, since they depend only on the interface abstraction; low, manageable complexity; as everything is isolated, you won’t need to worry about rippling changes; this dramatically decreases the complexity of your code; low cognitive load; with decreased complexity, your brain will be free to focus on what matters; Thank you for all the discussion, my thoughts on this issue is clearer now :)

Hello @Uwe Raabe, Assume I've just opened the method editing window, and I want to quickly select the second parameter then make modifications. What's the fastest shortcut for it? The one I know is [Alt + M] to jump to 'Modifier', the npress [Shift + Tab] to jump back to the Parameter List, and then press Down Array to select the next parameter. I wonder if there is any faster way? Thanks.

Thanks Uwe!

Well, maybe there is some misunderstanding here. Actually I mean 'consider', NOT 'use composition without considering inheritance' as you said. If I didn't describe it clearly, any native English speaking members here to correct me :P In other words, one should consider composition first, put composition in the first place, only if it doesn't fit, then try consider inheritance. Why so? That's the conclusion I made after I have read a bunch of articles on the topic of 'Prefer composition over inheritance', some of which I listed in my original post. Please note the word 'prefer', it doesn't mean 'conditioning yourself to use composition without considering inheritance' as you said above. And as A.M. Hoornweg above has pointed out: That's exactly what I meant in my original post: The coupling here is conceptual, not on the compiler level - the descendant class and the client knows too much methods about the base class, and that's where the unclearness begins. Finally, let me quote from the first linked article by Nicolò Pignatelli, he describes the idea of 'composition over inheritance' much better than me:

Let me reiterate it - need not to say, both inheritance and composition have their own application situations, there is no doubt about it. The point is, to simply put, always consider composition first before you inheriting a class, if both can do the job, prefer composition over inheritance. That's all about the point.

You miss the 'code reuse' part of the original question. In other words, if your purpose is code reuse, think twice before using inheritance, in most cases, maybe composition is more suitable, this may sound extreme, but just as the first linked article said, I tend to try use as less inheritance as possible. And that's the question I want to discuss with your guys here. I didn't mean never use inheritance - when your purpose is polymophism, you need inheritance. Do you know the circle-ellipse problem? That's the problem of inheritance.

That's the mistake people often make, otherwise there won't be the God Object wikipedia page :)

@Dalija Prasnikar I'd like to add two things: I believe you are talking about implementation inheritance but not interface inheritance. The common mistake to make when using implementation inheritance is creating God Object.

@Dalija Prasnikar Thanks for sharing. Correct, it depends on the specific situation, I agree with you, except that I somehow think the 3 things you mentioned - delegation, composition and aggregation are the same thing.

Thanks for sharing your thoughts. I think inheriting from TObject, TPersistent, TInterfacedObject, and so on, are ok and necessary, because in that case the inheritance is about polymorphism, not only code reuse. So it's another case I think.

DLL seems to be the way to go. This reminds me the now on going discussion about not to buy a library without source in the other thread which announced a new commercial SVG library library.

Will deleting all Delphi generated dcus (not those shipped with Delphi) files from your entire system work? Also try enable Remote Debugging in the project options. I used to had the same issue with an earlier version of Delphi and this strange tricked worked somehow.

There are several things worth trying if you haven't done it yet: Clean the project in the Project Manager, then rebuild. Search and delete all .dcu files generated after your initial Delphi installation from your system entire system, and then rebuild. Search Everything is your friend. I assume you don't use CN Pack's Input Helper? It has issues in the recent versions, I had to revert an early version (CnWizards_1.1.4.933_Unstable.exe)

Would love to know how it compares to madExcept's leaks report, from the GIFs I found they are very similar to each other.

Hi Thomas, I'd like to bring this to your attention - I created a ticket about suppressing all error dialog boxes during the GREP search, over a week ago. On the other hand, I'm wondering if is it possible for me to make svn commits to the repository for fixing small issues like this :)

Hi Thomas, Where can I find your email address? Would you send it to me via private messaging? Thanks.

I don't know much about the SVG format - do you happen to know is animations a part of the SVG standard spec?

Very interesting! That's something I thought of for several times in the past.

Me too!

It's also the same question that occurred to my me after skimming through the webpage and running the precompiled demo.

If you don't mind me extending this topic a little bit, I think the IDE support for generic collections really needs to be enhanced - when you Ctrl + Click on a generic collection class or its member, the code editor won't take you to the code definition like it does for a non-generic class. I just tested Delphi 10.2 and it has the same flaw, not sure about 10.3.

Not sure, I don't use dbx all all, and I couldn't think of any recent operations of me to the IDE that might case the change of that file. I disabled the .bpl file as suggested by Thomas and the problem seems to have been solved. Thanks.