Video via +Kristian Köhntopp “Die 90er haben angerufen und wollen ihre Amiga Videos und ihre Corba Specs zurück haben.” (the 90s called wanting their Amiga Videos and Corba Specs back)
Because of collision: though hardly documented in the early Delphi days the standard function TypeInfo has been there forever so System.TypeInfo already takes TypeInfo in the global namespace as the System unit is used by default and doesn’t have a namespace prefix.
One more reason to suffix unit names with a word like Unit.
And one more reason to always get a Delphi version with source code for RTL/VCL/…: it’s an invaluable source for not so well documented things.
DUPLICATEENABLE is old, but since it is something for IDE packages to avoid intersections with user/3rd party packages there is no need for a documentation. I do use it in an IDE package that did use the JCL/JVCL units as well and does another unit with a common name. IIRC I did mention it related to MonkeyMixer.
I think he argues that documentation is both not needed, but the usage of the directive sometimes is. Which somehow feels like a contradiction to me.
PS2: via Stefan Glienke, an error message that is related to this:
---------------------------
Error
---------------------------
Cannot load package 'Package2.' It contains unit 'Whatever', which is also contained in package 'Package1'.
---------------------------
OK
---------------------------
Windows 10 Creators Update 1703 caused issues with all Delphi programs, libraries and packages because it changed how Windows loads imported DLLs in such a way that it causes performance issues and can crash the debugger.
Delphi 10.2 Tokyo Update 2 fixed this by not producing multiple dll import sections for one DLL anymore.
IDE Fix Pack 6.1 implements that “feature” for all previous Delphi versions (2009-10.1 Berlin) and extends it to not only eliminate duplicate dll imports but also duplicate delay dll imports.
There are also (optional) updates that you can enable with new compiler switches:
Eliminating fwait instructions (but be careful, as they can confuse the debugger)
Optimising calls to virtual methods through interfaces
TFileStream.Create('c:\a.txt', fmCreate or fmShareDenyNone).WriteBuffer(Pointer(TEncoding.UTF8.GetBytes(BigStringVar))^,Length(TEncoding.UTF8.GetBytes(BigStringVar)))
They all work form the debug inspector, but they do leak memory. See comments below.