Jump to content

Rudy Velthuis

Members
  • Content Count

    285
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Rudy Velthuis

  1. Rudy Velthuis

    Anon methods passed as event handlers?

    If the "implementation details" make them much heavier (i.e. have much more overhead), because they require the generation of an object and an interface and the capture of local variables, then these details do matter. The current types are also easy enough to use. Yes, there is sometimes confusion about the fact you can't assign a simple prodcedure to an event, but that is it. That is is not a good reason to use all these complex types everywhere. Heck, even if a proper event method explicitly has to call a simple procedure, then that is still far less overhead than an anonmeth.
  2. Rudy Velthuis

    Anon methods passed as event handlers?

    Yes, I guess so (i.e, I don't doubt it). You can assign a normal procedural type and a method to a "reference to" pointer, but the latter is not really a simple type. Compared to them, procedural types and method pointers are far more lightweight. If they had used something like anonmeths for events from the start, I am sure that people would already have called for simpler types instead, like what we have now.
  3. Rudy Velthuis

    Anon methods passed as event handlers?

    C# delegates are terribly complex, and that is why they work the way they do. Delphi has more or less lightweight implementations for procedural and method types. Good for us. So I'll repeat it: If people want the complexity of C#, then they should use C#.
  4. Rudy Velthuis

    Anon methods passed as event handlers?

    Yes, indeed, in agreement with me. Hmmm... they could have introduced it for FMX, I guess, but I'm still not sure if this would have been a good idea. If people want the complexity of C#, then they should use C#. <g>
  5. Rudy Velthuis

    Anon methods passed as event handlers?

    What problem? I don't see any problem. Yes, the implementation details are what makes these types incompatible, and perhaps this can be done differently, with a lot of changes in the implementations, But what would the big benefit be? Is it worth it? IMO, no.
  6. Rudy Velthuis

    Anon methods passed as event handlers?

    That's cool. ISTM that for Delphi, it would mean quite a few changes in the compiler. And well, I still don't see why it should be done.
  7. Rudy Velthuis

    Anon methods passed as event handlers?

    Does it? I haven't been using C# a lot, lately, but AFAIK, C# does not have global (non-method) functions. It may have static functions, but can you assign those to a delegate? Can you assign its equivalent of an anonmeth to an event?
  8. Rudy Velthuis

    Anon methods passed as event handlers?

    They were never "impossible". At the timeframe of Delphi 7 generics were already being considered. ARC was not on the horizon yet, but it was never considered "impossible". Fact is that some things might have been missing that made their implementation impossible. But that does not mean that everything you can conceive is possible, or, even if it is possible, if it makes sense. The current distinction between plain procedural types, method pointers and "reference to" pointers makes sense. It doesn't make sense to try to unify them, as the underlying concepts are already different.
  9. Rudy Velthuis

    Anon methods passed as event handlers?

    I don't think that makes sense. If that type would be able to catch simple procedurals, methods and anonmeths, it would have to be prett complex, and why would you want to use a pretty complex type for even the simplest (plain procedural) function? Also, an event needs two things: an object and a code pointer. It can't do without. A plain or static function does not have those, An anonymous method does not necessarily have these either.
  10. Rudy Velthuis

    Anon methods passed as event handlers?

    No, it shouldn't, not in theory and not in practice. You have a different signature. An anonmeth is not a TNotifyEvent. They are two very different beasts.
  11. Oh yes, of course. I misread. Sorry. I don't think I can cancel (delete) that message?
  12. FWIW, Pascal only has two: for-to and for-downto. The for loop in Pascal is quite simple, but in the olden days, I guess the fact that it was easier to write and the fact that is was dedicated to increment or decrement an integer to a preset limit made it faster too. These days, with optimizing compilers, the difference is not that big anymore. Note that the synatx is very similar to what other non-C-style languages had, like Basic or several versions of Algol (which predate Pascal, AFAIK). The third way, for-in, is a Delphi/FreePascal/Some_Other_Dialect construct only. More here: https://en.wikipedia.org/wiki/For_loop
  13. Rudy Velthuis

    Forked VSCode for Delphi

    Like the late Ed Mulroy (TeamB) once wrote:
  14. Rudy Velthuis

    Deep Dive into Design Patterns

    I like and use design patterns a lot. but there is one thing that bothers me: I can't remember all their names or I start confusing similar ones. Reading books avout them is like reading those books with hunderds of names in them. <g> But seriously, that is why I always have big problems following discussions about them. I keep having to look up the patterns under discussion before I can say something. FWIW, I have the same problems with dental and surgical instruments that are named after their inventors. These names do not tell what these intruments do at all. I almost always use their functional names instead.
  15. Rudy Velthuis

    Forked VSCode for Delphi

    Most of the time you write code. But sometimes you do need a form designer, and if you don't have it, things get very, very tedious. If you want to code FMX, this gets even worse. I may be biased, because I have been using it since Delphi 1 was released, but IMO, the code editor is fine. I have used many many other editors, on different platforms (DOS, OS/2, Windows, macOS, Linux), but I don't think they are much better. Especially the Delphi editor is the best to search code, to search implementation and everything else that only can be done with a dedicated editor. Other editors may have some niceties, but in my experience, they don't weigh up against the many conveniences a dedicated editor provides. I don't care about themes or languages like python or JavaScript in the Delphi editor. And the dedicated debugger in the Delphi IDE beats all others.
  16. Rudy Velthuis

    Forked VSCode for Delphi

    I assume you have been using Delphi for two years now and not that your actual age is 2 years? I've been using Turbo Pascal since 1985 and later Delphi since 1995, so a little longer than that. If you want to do that, feel free. But I rather stay with Delphi's IDE. It is as tightly coupled to Dephi as can be, and changes to FMX or VCL will be reflected in the designer too. FWIW, the Delphi IDE can easily be extended too, and you could implement the features you find lacking. Take a look at GExperts or cnPack or some of the other experts/wizards/plugins that extend the IDE.
  17. Rudy Velthuis

    Handle parallel.foreach exception

    Not an answer, but I'm just curious: why &Foreach? AFAIK, foreach is not a keyword.
  18. Rudy Velthuis

    Tree view?

    Daniel, you wrote elsewhere: " The tree-based layout of a usenet-group allowed yo to discuss side-aspects for ever. But here this style just captures a whole thread. " If I go to the original German Delphi-PRAXIS, I see I can actually choose a tree-based layout, more or less like in a newsreader, and it even has a useful navigation (next message, previous message and at the bottom next thread, previous thread). Would that be possible here too? I love it in the German forums. I guess it would vastly improve the layout for those used to NNTP-based threads.
  19. Rudy Velthuis

    Tree view?

    I think my view (which is exactly the same) is well known by now.
  20. Rudy Velthuis

    Tree view?

    Ok, thanks, I understand it is not very likely we'll ever see it here. Although, I don't understand why others don't prefer it. I do use it in the German forums, and nothing can beat it.
  21. Rudy Velthuis

    On-demand ARC feature discussed

    What do you think I am doing? I am telling him that the discussion is over.
  22. Rudy Velthuis

    On-demand ARC feature discussed

    Everything has been said about it. Having two incompatible object models that can't be mixed is a mess.
  23. Rudy Velthuis

    On-demand ARC feature discussed

    It would make it slow and a terrible mess. No thanks.
  24. Rudy Velthuis

    On-demand ARC feature discussed

    I explained it already. You really can't get enough, can you?
  25. Rudy Velthuis

    On-demand ARC feature discussed

    What Marco Cantù already said in one of the early threads on these forums: it was about what is probably the replacement for ARC, i.e. a way to (more or less automatically) manage the lifetime of objects that is not ARC. Even inline declared variables are part of that strategy. The replacement is most definitinely not the mixed ARCs discussed in this thread.
×