Georgge Bakh

Did someone compare it to https://github.com/BeRo1985/flre ?

Find usages is one of the most useful and most frequently used features of a code editor. Must work flawlessly.

@Remy Lebeau Generics are OK. And very useful. But some implementations are not. 😉 Btw in FPC your code compiles and working properly.

You can use unit scopes for this as partially done in RTL. Place things which need different implementation for different platforms in separate units per implementation. E.g. Windows.Utils, Linux.Utils etc. Or even not bound to a platform but API: OpenGL.Render, DirectX11.Render etc. In uses clause of other units just write Utils or Render. And setup needed unit scope names in project settings - Windows;OpenGL. This approach with some architectural effort will minimize number of IFDEFs in code.

Tried to use generics to parametrize a class with some code. type TTest1 = class procedure Test(); end; TTest2 = class(TTest1) procedure Test(); end; TTest<T: TTest1, constructor> = class(TObject) FTest: T; procedure TestIt(); end; When calling FTest.Test() I expect a method of actual type parameter to be called. procedure TTest<T>.TestIt(); begin FTest := T.Create(); FTest.Test(); readln; end; But actually a method of type constraint (!) is being called. I.e. static type of FTest not depend on actual type parameter. It's always TTest1! Is there a workaround for this? How do you parametrize generic classes with code? Comparators, hash calculators and other useful things which give generics a purpose. It's an essential part of generics which simply not work! How this bug can not even be reported till now? The code works as expected with Free Pascal Compiler. https://quality.embarcadero.com/browse/RSP-27840

I've checked. As Stefan said if TTest2 is sealed or its method Test() is final the call is non-virtual. If type parameter of TTest is constrained by an interface the correct method is called but despite non-virtual declaration of Test() method the call looks like virtual (FPC inlined the call). GetTypeName(TypeInfo(T)) is 'TTest2' in both cases. Overall the current behaviour of generics in Delphi seems to be too restrictive without any gain. May be in C# it's acceptable because it does have many other capabilities and aggressively optimizing JIT compiler. But for Delphi it's not suitable.

@Kryvich Just curious - what else could output this code? I'm aware of FPC approach to generics and it's much better IMHO. Although not complete too. As of virtual calls - when writing a low-level library code there is not known where exactly it will be used. So trying to avoid virtual calls it normal especially when those are absolutely unnecessary. Thanks for help. Later will check and bench with sealed/final. And will decide on a choice to use ugly IFDEFS or drop Delphi support.

OK, C# is an authority here and my approach is totally wrong. But how it can be achieved in compile time? The task is simple: I have a class, let's call it TDataHandler which use another class as data provider - TDataProvider. TDataProvider can be a simple wrapper over a memory buffer or more complicated stream-based implementation or something else. In TDataHandler I call TDataProvider to get some data and several other data-related things. I could declare methods of TDataProvider as virtual and override them in actual implementation but I don't want to have virtual method calls (non-virtual is acceptable) instead of simply referencing a pointer (as generated by FPC). How it can be done? Please note that in Java (and probably C#) virtual calls is not a problem as JIT compiler will inline even virtual calls if needed and the resulting machine code will be similar to one generated by FPC.

David, if I got you right, your advice is to use the technique with virtual methods because it works. It's a good advice thank you. But I wanted to use generics as it's a powerful technique which I successfully use in other languages and it seems it should work for my case. And a broad range of other cases which can be identified as parametrization by code. If it can't be done in Delphi it's sad but I'd want to know why. Is it a bug? Let's get on with it: I have TTest<TTest2> specialization of the above generic class TTest. May I expect that field FTest will have static type TTest2? If no why?

If I'd wanted virtual methods I wouldn't use generics. Just field of some base class is enough. But it's not a compile time parametrization. It's runtime technique. Why? My logic is: TTest<T> has field FTest of type T. Therefore specialized TTest<TTest2> will have field FTest of type TTest2. How the field can be of type TTest1? TTest1 is just a type parameter constraint after all. It's needed only to allow the use of Test() method in code.

I hope there will be something that justifies such a secrecy.

My collections library based on pseudo-templates has a HashMap implementation. Besides of key and value types it can be parametrized with a hash function of the default one is not suitable for some reason. https://github.com/casteng/tacl

If I got it right, you protecting with a critical section (the same one I hope) read access to fields as well as field modifications with change event call. This may be or may be not enough depending on what your program do and what invariants you must ensure. Additionally, with some logic in change event handler there is a risk of deadlock.

Look like Free Pascal has these features. Besides Basic support. Did you considered it? Compiler development is very interesting area. I think you will find people if you decide to go that way.

Self signed certificates can be validated as usual. If lets say a server certificate is self-signed than a root CA certificate which was used for signing (may be self-signed as well) should be trusted by client. If both server and client data are under control it's possible to make the CA certificate trusted. That's how browsers work after all. Diffie-Hellman key exchange by itself doesn't protect from MitM attacks.

If multiple server sides are planned (for each customer?) it's better to generate own certificate/key pair for each customer. There is no much reason to use TLS for already encrypted data.

When an open source project doesn't have a precise release date it's not good but still ok. Especially considering the fact that the project is not backed by IBM, Google or other big entity and people working on the project on spare time.

Regardless of is WITH statement good or is it bad it's a part of language and debugging, refactoring and other code tools should be aware of it. As a bonus, it may also hint which identifiers come from which scope

I-Pascal reports unused units on the fly and the ones which can be moved to implementation as well. And can apply the changes automatically as well as mark some unit in uses useful to not report it anymore. As of class helper case - interesting case, need to think about it. Even this is not absolutely reliable as you mentioned. But working with AST can give acceptable result.

When a check fails the result of the chain call is an object of a special class (TFailedValidator?). Which let say hasFailed() method returns True. 🙂 Depending on actual code of Validator and TFailedValidator you can check what happened and decide what to do. In addition to other answers, explicit checks can act as contracts which can be easily read and also used by IDE and/or external static code analysis tools.

With these requirements the solution may be something like: Validator .Check(value <> nil, 'Value is nil!') .Check(str <> '', 'String is empty!') .Check(Value.Num > 0, 'Value.Number <= 0!'); Check() receives a boolean to check and string message to complain. If boolean is true returns Self. If false - other instance whose Check() method just returns Self on any input.

This is the primary goal of a good package manager. But I agree - GetIt obviously can't achieve it by design.

To avoid unit cycles your form units should not depend on a unit which actually translates anything. Them should depend on some interface ITranslator which have methods TranslateProject and TranslateControl. Each unit create the implementation on demand with some kind of factory. E.g. Translator := TFactory.CreateTranslator(); The factory may be implemented as a simple container for implementations. E.g. actual implementation class (which depends on all forms) at some point during initialization registers itself as implementation of ITranslator interface. With this design you don't have unit dependency cycles. In real life case it's better to use some DI container for this instead of creating it by yourself. This is because there is a cycle indeed. You cannot declare mutual units dependency in interface sections. At least one unit should use the other from implementation section. Otherwise the code will not compile.

I'm not aware of any extensions with such effect. May be mighty LSP will bring this feature (no). I-Pascal (Pascal support plugin for Intellij IDEA which I develop) does this. Also I think I saw Lazarus does this too but can't find it in 2.0.2. And I agree with @David Hoyle - it's not an easy to implement feature.

Good idea. Indeed SynCommons already contains many highly optimized routines and there is not much sense to duplicate it. But I believe there is still much to do. As of platforms - besides i386 and AMD64 there is ARM which is very interesting and much less covered with optimized code.