Jump to content

Georgge Bakh

Members
  • Content Count

    34
  • Joined

  • Last visited

  • Days Won

    1

Georgge Bakh last won the day on May 15

Georgge Bakh had the most liked content!

Community Reputation

21 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Georgge Bakh

    handling predicate conditions

    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.
  2. Georgge Bakh

    handling predicate conditions

    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.
  3. This is the primary goal of a good package manager. But I agree - GetIt obviously can't achieve it by design.
  4. 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.
  5. 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.
  6. 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.
  7. Georgge Bakh

    Funny Code in System.Types

    A bit of static analysis should be enough in that case.
  8. Georgge Bakh

    Best delphi so far?

    I have no idea what is the difference for an IDE are units included in .dpr or not. But what is the purpose of including in uses clause of a .dpr units which are not actually used in that file? What if a unit become shared between projects (i.e. become a library)? Should it be removed from .dpr?
  9. Georgge Bakh

    Best delphi so far?

    Again, I didn't stated that it's simple. I know that dealing with broken code is hard. But it should be a code tools developer problem. Not users.
  10. Georgge Bakh

    Best delphi so far?

    I didn't say that dependency cycles are a good thing. I trying to avoid them myself. But it is not always possible due to lack of a bigger visibility scope than unit. But I still think that code tools should not break or slow down with unit dependency cycles. And I know what I'm talking about as writing pascal code tools is my current pet project.
  11. Georgge Bakh

    Best delphi so far?

    Honestly, I see no reason why these things should cause slowing down or breaking of code tools. Code tools must work regardless of code style used.
  12. Georgge Bakh

    where to find FMX 3d coders?

    I think you can do it right here. Also there is a Facebook group "delphi developer" and a section at russian firemonkey community: http://fire-monkey.ru/forum/77-ищу-подрядчика/
  13. Georgge Bakh

    Java Updated License Terms and Delphi

    For development it's still free even for commercial organizations. https://www.oracle.com/technetwork/java/javase/overview/oracle-jdk-faqs.html But you always can install free version (Oracle's OpenJDK) from here: http://jdk.java.net/
  14. Georgge Bakh

    Payment - Monetization - Good international PSP

    Some time ago I sold shareware games (written on Pascal btw) and used Plimus to receive international payments via cards. Now its site redirects to bluesnap.com and seems this company does the same thing even cheaper. And there are many other companies which you can use to receive payments. Most of them can provide all necessary papers for companies/corporations.
  15. Georgge Bakh

    RadStudio Roadmap 2019

    No. With LSP tools like VS Code and many other editors will offer error insight, code completion and some other services for Pascal language. But this: When (if?) these plans become reality other IDEs will be able to offer debugging for Pascal language. IDEA with I-Pascal already supports LLDB. I hope the language support in LLDB will be better than in GDB otherwise debugging experience will resemble one from Lazarus.
×