Stefan Glienke

There is no RTTI available for interface properties - you have to refer to them via the setter method name. And even that only works if the interface has {$M+} or inherits from IInvokable.

Sounds like an idea for a new rule to add for FixInsight and alike

https://www.idefixpack.de/blog/ide-tools/ide-fix-pack/ and https://www.idefixpack.de/blog/downloads/ both say "10.3 (RTM/UP1/2/3)"

That code would not even compile as the two New overloads in TBase don't differ from each other parameter wise.

If an object implements many interfaces it handles many responsibilities and not only a single one (SRP). You can use aggregation and delegation of those interfaces.

Look into TActivatorContainerExtension

Write your own ConstructorSelector that does not want the one with the most parameters.

@Clément Did you actually read the very first post where it said: So the question is about the best data structure or algorithm to delete those items from the list and I am very sure the algo TList<T>.Pack uses is the most suited one. It is one iteration with batch moving remaining items to the front. The most impactful thing here will probably be calling the delegate to determine if the object should be removed and the dereferencing of the object reference to read some field that holds the information to give that information.

Then you are doing something wrong - can't repro {$APPTYPE CONSOLE} uses Spring.Container; type TModifyingSQLKind = (SQLInsert); TSQLDataSuiteWorkerMethod = procedure of object; ISQLDataSuite = interface ['{068D3552-CBA6-4AAE-9061-59FA6407FF8C}'] end; TSQLDataSuite = class(TInterfacedObject, ISQLDataSuite) public constructor Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL : Boolean); overload; constructor Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL : Boolean = True; const aBeforeWorkerMethod: TSQLDataSuiteWorkerMethod = nil; const aAfterWorkerMethod: TSQLDataSuiteWorkerMethod = nil); overload; end; ISQLDataSuiteFactory = interface(IInvokable) ['{A101FA06-ED33-478A-9066-821BC8C5E2AE}'] function Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL : Boolean ): ISQLDataSuite; overload; function Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL : Boolean; const aBeforeWorkerMethod: TSQLDataSuiteWorkerMethod; const aAfterWorkerMethod: TSQLDataSuiteWorkerMethod): ISQLDataSuite; overload; end; { TSQLDataSuite } constructor TSQLDataSuite.Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL: Boolean); begin Writeln('create'); end; constructor TSQLDataSuite.Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL: Boolean; const aBeforeWorkerMethod, aAfterWorkerMethod: TSQLDataSuiteWorkerMethod); begin end; var fSQLDataSuiteFactory: ISQLDataSuiteFactory; begin globalContainer.RegisterType<TSQLDataSuite>.Implements<ISQLDataSuite>; globalContainer.RegisterFactory<ISQLDataSuiteFactory>(); globalContainer.Build; fSQLDataSuiteFactory := globalContainer.Resolve<ISQLDataSuiteFactory>(); fSQLDataSuiteFactory.Create('TableName', TModifyingSQLKind.SQLInsert, True); Readln; end.

Leave the pub once you reach the Ballmer Peak and then work on your program to make it even better

Of course but I am assuming that Steve is doing more with this list than just removing many items at once. My personal experience with collections and a lot of material I read and watched is telling me that the chances are kinda slim that a linked list will perform better in the overall usecase. Anyhow in the context of this question any discussion of this is moot and my first sentence in my first comment still stands. Anything else is a waste of time.

Ask google and read up on prefetchers and cache locality.

When looking for the correct constructor to match the algo tries to match the parameters given with the parameters required by the constructor. However it does not allow injecting nil which is the reason it does not consider this constructor. As for a subforum - there is already a forum for Spring4D at https://groups.google.com/forum/#!forum/spring4d

RemoveAll is the way to go - it is optimized internally for lists (at least since 2.0/develop) - not yet for dictionaries but there it more depends on what is the criteria for deleting items as remove by key is already O(1) The approach with Where/Remove does not work because the result of Where is lazy evaluated and will raise an exception once the source gets modified (after the first deleted item). Even when calling ToArray to manifest the collection of to removed items the Remove will be a waste of time because items would be searched all over.

Measure, don't guess - basic rule of performance tuning Linked list is a bad idea btw - if anyone thinks otherwise he needs to get an update on modern CPU architectures.

GetKeyState and related WinAPI functions are broken with Numlock enabled - and you are not the only one suffering from this defect if you google for numpad shift stuck If you release the shift key first it never sees the keyup of the insert key (which the shift key turned the numpad 0 key to). You have to use other ways to do that

Use diff tool/setting that also shows whitespace/eol differences

If there are no generics it's a different issue than RSP-27000.

The reason is they added a converter for encoding fields in TStrings to Data.DBXJSONReflect so it writes it different from before.

I just tested it and reduced the code further to pinpoint the wrong behavior, added additional information and reported as RSP-27000

Emba does not contribute to open source - especially not GPL

The TypeInfo uses the value $80000000 to indicate that this property has no default value. That unfortunately overlaps with Low(Integer). You have to use the stored keyword: property MinValue: Integer read FMinValue write SetMinValue stored IsMinValueStored; function TMyComponent.IsMinValueStored: Boolean; begin Result := FMinValue <> Low(Integer) end;

Because!

The point is that DestroyWnd is never called on the TForm (tested with 10.3) thus FDropTarget never destroyed.