Jump to content

Georgge Bakh

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Georgge Bakh

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

    I-Pascal 2.0

    I-Pascal v2.0 has been released. What is I-Pascal? It's a Pascal language support plugin for IntelliJ IDEA. Integration with Delphi and Free Pascal Compiler. The main goal of the project is to provide modern code editing and inspection tool for Pascal language. Dependency cycles ready. In the new release: Completion options from not used yet units (with automatic modification of uses clause) Completion itself is improved and not is comparable to one for Java Delphi 10.3 inline declarations syntax support. Highlighting, find usage, renaming etc. No inherited destructor call inspection Project site: http://siberika.com/ Installation instructions: http://siberika.com/install.htm Source code: https://github.com/casteng/i-pascal
  17. Georgge Bakh

    I-Pascal 2.0

    Just uploaded a new version. Now it supports "introduce variable" refactoring, parameter to field binding and other features. Change log with animation: http://siberika.com/whatsnew.htm
  18. Georgge Bakh

    Git UI tools

    I think IDE should support version control systems integration. Delphi has it at some basic level. I use IntelliJ IDEA as Pascal IDE and do most Git operations within the IDE as it comes with very good integration of various VCS including Git.
  19. Georgge Bakh

    Forked VSCode for Delphi

    Yes, when someone from "outer world" comes to Delphi ecosystem IDE is the first thing to be discouraged with. Because there are many serious problems indeed. It's a good idea to take an existing high quality and extensible IDE and use it as a base for new Pascal IDE. I think it's much better than try to extend Delphi IDE with plugins. The base platform should be designed with many things in mind: indexing, threading, data integrity, real time code analysis, cross platform to name a few. UI is also an important (and often underestimated!) part. On the other side I see no reason to recreate a form designer. It's good enough in Delphi (or Lazarus). What's about a language server - it's good to have to bring Pascal support to many editors at once, but it's not a way for first-class IDE.
  20. Did you know that this Java IDE can do the same thing for Pascal code too? After installing a plugin for Pascal support of course.
  21. Georgge Bakh

    Unused local variables

    I-Pascal highlights unused local identifiers in real time. Whole project can be inspected as well by "Analyze->Inspect Code..." menu option. It really can save some time preventing bugs getting into the code on early stage. So I think this is a must have feature for a modern IDE.
  22. Georgge Bakh

    Extremely useful feature

    Is it just an ordinary identifier usages list?
  23. Georgge Bakh

    Blogged : Delphi Package Manager RFC

    With dependency management done right libraries will become simpler, easier to maintain and of course more uniform.
  24. Georgge Bakh

    Blogged : Delphi Package Manager RFC

    I'd say in Free Pascal as such tool should be crossplatform and work for FPC too.
  25. Georgge Bakh

    Blogged : Delphi Package Manager RFC

    Very good initiative! The absence of dependency manager is a big problem of Pascal ecosystem. Not only CI scenarios suffers from it but library developers - there is no option to make a library dependent on another library as it become too complicated for most people to install and use it. So most libraries have *commons.pas units which contains pretty same purpose routines and classes. I thought about it a lot and the only reason why I not started such a project is that I believe it should be a community effort. Or we'll end up with another package manager without packages and users. I'm familiar with Maven from Java ecosystem and it does it's job well. Some quick thoughts: I see no much sense binding it to a particular IDE or even compiler. Let it work for FPC too! Components and packages are good but libraries are also good and much easier to manage. I think such a tools should have a command line based core with plugins for IDEs when needed. In that case CI server will be able to build project from scratch as it should be. Simple workflow - a project config file at input and a directory structure with library/package files at output. A package can be identified with an ID - something domain name-like works good here and partially solves problems with copyright etc. Please no GUIDs here! To identify a dependency seems to enough: (ID, version, compiler/platform, type) type is source or binary (dcu/ppu). Therefore, to use a library it's needed to create a config file and run the tool. After it ends its work there is a ready to use directory structure with all needed files and maybe even compiler config file with paths.