Edwin Yip

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

Hello, I don't remember since exactly when, but about a few weeks ago my XE4 IDE complains about "duplicates not allowed" when opening a project. Here is the call stack caught by madExcept. It seems has something to do with the Interbase DBX driver which I don't use at all and I can disable it, if anybody kindly tells me how. Any hints would be appreciated! Call stack === operating system : Windows 7 x64 Service Pack 1 build 7601 system up time : 20 hours 57 minutes program up time : 15 minutes 43 seconds processors : 4x Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz physical memory : 1497/7888 MB (free/total) free disk space : (C:) 50.49 GB (F:) 1.66 GB display mode : 1920x1080, 32 bit allocated memory : 306.80 MB largest free block : 116.06 MB version : 18.0.4905.60485 compiled with : Delphi XE4 madExcept version : 4.0.19 callstack crc : $c606e1f1, $46f22a97, $9846ea67 exception number : 5 exception class : EListError exception message : Duplicates not allowed. main thread ($1b08): 07b089fa +046 DbxCommonDriver180.bpl System.Generics.Collections 1764 +7 Data.DBXClassRegistry.{System.Generics.Collections}TDictionary<System.string,System.TClass>.Add 07c00586 +032 DbxCommonDriver180.bpl Data.DBXMetaDataWriterFactory 66 +1 TDBXMetaDataWriterFactory.RegisterWriter 06fbd175 +019 DBXInterBaseDriver180.bpl Data.DbxInterBaseMetaData 23 +1 Data.DBXInterbaseMetaData 50060476 +042 rtl180.bpl System 20618 +18 InitUnits 500604e6 +046 rtl180.bpl System 20643 +8 @PackageLoad 29111425 +005 DataExplorerDBXPluginInt180.bpl SysInit 898 +0 @PackageLoad 5009ee43 +03b rtl180.bpl System.SysUtils 23373 +4 InitializePackage 59859a2f +01b madExcept_.bpl madExcept InterceptInitializePackage 5009ef9b +083 rtl180.bpl System.SysUtils 23424 +18 LoadPackage 204c1e78 +008 coreide180.bpl PakLoad 146 +0 TPackage.DoLoadPackage 204c1fed +055 coreide180.bpl PakLoad 220 +7 TPackage.Load 204c4941 +061 coreide180.bpl PakMgr 591 +2 TDesignPackage.Load 21c99b07 +05b delphicoreide180.bpl PasCppPakMgr 2292 +4 TIDEDesignPackage.Load 5005f2a9 +01d rtl180.bpl System 16534 +2 @AfterConstruction 21c9991b +06b delphicoreide180.bpl PasCppPakMgr 2217 +11 TIDEDesignPackage.DelayLoad 21c93f82 +09e delphicoreide180.bpl PasCppPakMgr 463 +10 LoadDesignPackage 21c94275 +215 delphicoreide180.bpl PasCppPakMgr 534 +52 LoadProjectPackages 21d7f22b +167 delphicoreide180.bpl BasePasProjOpts 1544 +22 TProjOptsManager.DoLoadPackages 21d8001c +000 delphicoreide180.bpl BasePasProjOpts 1779 +0 TProjOptsManager.LoadPackages 21d81030 +008 delphicoreide180.bpl BasePasProjOpts 2353 +1 TProjectOptions.LoadPackages 21ccd845 +17d delphicoreide180.bpl BaseDelphiProject 2787 +21 TDelphiProjectModuleHandler.Create 21ccc6b5 +009 delphicoreide180.bpl BaseDelphiProject 2415 +0 TBaseDelphiProject.InstallModuleHandlers 223c46e9 +005 delphide180.bpl DelphiProject 91 +1 TDelphiProject.InstallModuleHandlers 21cc3c41 +299 delphicoreide180.bpl BaseDelphiProject 767 +49 TBaseDelphiProject.Create 223c5236 +04e delphide180.bpl DelphiProject 267 +5 TDelphiProjectCreationTrait.OpenMSBProject 206df09d +181 coreide180.bpl ProjectFileUtils 701 +22 MSBuildLoadProjectFile 21cd629e +01e delphicoreide180.bpl BaseDelphiProject 4957 +3 TDelphiProjectFileModuleHandler.FileOpen 2086c99e +016 coreide180.bpl DocModul 3220 +0 TFileOpenHandler.FileOpen 208676d4 +130 coreide180.bpl DocModul 801 +36 TFilterList.OpenFile 2086b703 +03b coreide180.bpl DocModul 2622 +3 CallDefaultOpenProc 205abf0f +22f coreide180.bpl ProjectGroup 1495 +28 TProjectGroup.Create.@label 205a9a17 +0d3 coreide180.bpl ProjectGroup 820 +11 TProjectGroup.Create 205a8739 +09d coreide180.bpl ProjectGroup 484 +6 LoadMSBProjectGroup 205b3dad +035 coreide180.bpl ProjectGroup 3872 +5 TMSBuildProjectGroupFileOpenHandler.FileOpen 208676d4 +130 coreide180.bpl DocModul 801 +36 TFilterList.OpenFile 2086b703 +03b coreide180.bpl DocModul 2622 +3 CallDefaultOpenProc 50214247 +b23 rtl180.bpl System.ObjAuto 789 +258 ObjectInvoke 50215cb9 +1fd rtl180.bpl System.Win.ObjComAuto 290 +41 TObjectDispatch.Invoke 76187bc5 +00a USER32.dll DispatchMessageA 50580e8f +0fb vcl180.bpl Vcl.Forms 10290 +25 TApplication.ProcessMessage 50580eca +00a vcl180.bpl Vcl.Forms 10318 +1 TApplication.HandleMessage 50581205 +0c9 vcl180.bpl Vcl.Forms 10456 +26 TApplication.Run 764b343b +010 kernel32.dll BaseThreadInitThunk

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.

That solved the problem, thanks Thomas!

Hi Thomas, no, I didn't. Update 1: Sorry, did you suggesting a solution I should try or did you mean that might be what caused the issue?