The only "good" bug that I was aware of was fixed. Not sure about the bad ones...

The only "good" bug that I was aware of was fixed. Not sure about the bad ones...
http://blog.marcocantu.com/blog/2016-june-closing-class-helpers-loophole.html

Comments

  1. Not when we use it to fix RTL and VCL bugs that wont ever be fixed.

    ReplyDelete
  2. It's not a bug, it's a feature... or was :(

    ReplyDelete
  3. It's controversial kind of bug. It helped to address some bugs of RTL and VCL/FMX but that is not proper way to deal with them. They should be fixed (ASAP after reporting) by Embarcadero and not bypassed by helpers from users code. But my friends know me as naive person. :)

    ReplyDelete
  4. "An important point that was highlighted by this change in the compiler, is that in some cases libraries keep access to some information private without a full evaluation of the scenarios in which developers might need access to those fields or methods."

    This is a huge issue in so much OOP code. I've lost count of the times have I wanted to extend some functionality, like any good OOP dev should be able to, and then hitting the private wall.

    ReplyDelete
  5. Since `strict private` fixed this already and the Delphi R&D team has been really reluctant with introducing changes that break other peoples code in the past, I'm baffled by this compiler change.

    This is especially important as many long standing RTL and VCL bugs are in those private parts and can only be fixed by accessing those private parts.

    It's a shame they did this some 10 years after class helpers were introduced.

    Is there any seniority in the R&D team left?

    ReplyDelete
  6. Jeroen Wiert Pluimers You name it. I had zero information about this change before Berlin went live. The fix for that so called bug is only half baked as calling private methods from the helper is still possible.

    ReplyDelete
  7. Uwe Schuster You cannot access private methods via helper in Berlin - I just tried because I was surprised by your claim.

    ReplyDelete
  8. Stefan Glienke
    Apparently the following works:
    Don't have Berlin so cannot test.

    function TAsmHelper.GetPrivate;
    asm
      mov rax, [rcx.FPrivate]
    end;

    ReplyDelete
  9. Johan Bontes I've seen worse hacks, but seldom...

    ReplyDelete
  10. Alexandre Machado RTL issues we'll never fix like those listed in the blog post? We fixed 80%+ of those suggested during the beta

    Jeroen Wiert Pluimers This is not a change in class helpers, it is a fix in a bug. Was never documented or discussed publicly by Embarcadero -- only on some personal blogs. It was fixed when it was reported as a bug -- after a very long internal and beta discussion, as I wrote. The "senior R&D" team was OK for it, and (as I mentioned) we even asked some past senior R7D -- like the person who designed class helpers

    ReplyDelete
  11. Johan Bontes If you don't have Berlin then get out of this discussion ;)

    ReplyDelete
  12. Marco Cantù no software vendor is capable of fixing 100% of reported bugs, including Embarcadero. This 10 y.o. "feature" has saved my ass a few times and I still use it in some production code, not because I want to mess around with classes just because I can, but because I have to.
    That been said, really worries me the fact that Embarcadero is spending more and more time removing stuff that you decide that will hurt the "pure pascal universe". Also worries me the fact that developers, here in this same group, more and more create new discussions about "what should be removed from Delphi"... Removing things from Delphi won't bring one single new customer to Delphi, ever! It is time to wake up!

    ReplyDelete
  13. Private methods have pointers and there are method pointers and 1 + 1 = two. https://twitter.com/UScLE/status/741012652202332161

    ReplyDelete
  14. Alexandre Machado They are not removing things. They might not have added everything when they made a new platform (like AnsiStrings) - but adding a platform without supporting 100% of the features of the other platform is not removing things.
    Fixing a bug that was beneficial and people (including me) (ab)used this to their advantage is not something to complain about, period. If you have issues that you used these hacks for then make sure they are being reported and instead of fighting with them try to raise their attention for these issues. If the fixes for these issues are of general interest I guess you can get enough upvotes to raise their priority within R&D.

    ReplyDelete
  15. Stefan Glienke "If the fixes for these issues are of general interest I guess you can get enough upvotes to raise their priority within R&D". So fixing a bug in Delphi world now became a political campaign... LOL. "Get enough voters and your problems will be taken care of!". I don't agree with your point of view. So, let's just agree to disagree here.

    ReplyDelete
  16. Stefan Glienke 'They might not have added everything when they made a new platform (like AnsiStrings)' - um, they were (are) there all right, just blocked from public use.

    ReplyDelete
  17. Uwe Schuster What point are you trying to make? You access a private member in the same unit - big deal.
    Edit: Ok, it even works across units - now that is bad (or good, so can people stop complaining now and use this?) -.-
    Alexandre Machado It's called prioritization.
    Chris Rolliston Technical details - a new platform with some things missing does not equal removing.

    ReplyDelete
  18. Stefan Glienke I don't care about bugs in FMX platform, do you? But some other people do. In fact other people might be begging for a FMX bug fix right now, because maybe their application is not working as it should and his boss is starting to point fingers around... For that guy, that bug is the most important bug in the whole universe, does not matter what you or I have think about it. Period.
    Talking about voters, I'm thinking about starting a new campaign: "Let's remove goto and with from Delphi. I don't care if it will break someone code (including mine). Let's remove it from our pure pascal!

    ReplyDelete
  19. Alexandre Machado Good luck with that. I guess you will have supporters for that - for the with I would even sign myself.
    As for that guy begging for the FMX fix. He should learn how to fix that himself - there are various ways. I even fixed methods in the past of classes that I could not even write a helper for because they were in the implementation part of a unit - now what?

    ReplyDelete
  20. A decade old behaviour which developers depended on still being classed as a bug is a bit strange, has it actually caused any problems for Emb or was it changed simply because it is "wrong"?
    If it was going to be fixed it should have been fixed before it became part of the language.
    My suggestion would have been to change the documentation.

    ReplyDelete
  21. FWIW, I've managed to solve almost all the issues I've come across without resorting to hacking privates using helpers.

    For issues in the RTL and FMX (haven't touched VCL for some time now), I've been able to resolve them by copying the relevant unit and modifying the implementation section, thus not having to recompile all related units. Some seem to be averse to this idea; I'm averse to breaking OOP principles ;-)

    ReplyDelete
  22. David Nottage What about having to fix a RTL bug for a library which supports 12 different versions of Delphi? Do you think your workaround is still viable?
    I'll give you a concrete example: QC Report # 113139. AFAIK it is still open. Solved internally in IntraWeb using class helpers. The patch is applied to 12 (yes, TWELVE) different Delphi versions. Without it ANY ISAPI application (not only IntraWeb) running in a server with a different time separator will fail on Chrome 25+ (and you, the developer will NEVER know it!). Do you really think that changing the RTL source code is a viable alternative? I can answer that: NO it is not.
    Fortunately, I've removed the whole WebBroker thing from our ISAPI implementation and now I don't need any other fix. As a bonus it is now at least 200% faster than before as well.
    BTW: TWebBroker is severely bad designed. Everything is private. Nothing can be extended or fixed. Good luck with that you guys relying on it.

    ReplyDelete
  23. Alexandre Machado Yes, having to support a multitude of Delphi versions would be a drawback. Fortunately I'm not in that position :-)

    ReplyDelete
  24. First, I would like to ask people that are "voting" for this "bug" fix what real life issues they had with class helpers while they were able to access private sections. Beyond, usual breaking OOP principles, encapsulation, private should be private, blah blah theoretical stuff.

    It is quite obvious that other side, devs that have to fix (tweak) classes by accessing their private members have troubles, now when they no longer can do so.

    It is not a question of whether you can or cannot do something you need to do, but how much time and effort that requires. Not just when you make the change, but maintaining that code across different versions. Class helpers were easy to use, and you could make your change with few lines of code. All other options (including RTTI access, when available) require more work from our side.

    I expect that my development tool will make my life easier, not harder.

    Just the same following OOP principles makes my life easier.

    Bottom line is, I have to do my work - and that includes breaking OOP when I have to and when doing so requires less work (including maintenance work)

    Dogmatic approach to programming never works. It can work in 99%, but you cannot turn blind eye to the remaining 1%. If you are lucky, most of your work will be in that 99% domain. Sometimes, you will sit most of your time fiddling with that 1% where you have to be flexible.

    ReplyDelete
  25. Stefan Glienke
    The reason I don't have Berlin is because of this non-bug fix.

    ReplyDelete
  26. I think DevExpress has advised me to use this hack a number of times in the past, on their own controls. Hopefully they're going to be changing the scope of a lot of their class fields, else after upgrading my main app to Berlin, my customers are going to lose a lot of functionality

    ReplyDelete
  27. Thanks to Uwe Schuster, see http://stackoverflow.com/a/37761607/576719
    "How do I use class helpers to access strict private members of a class?"

    ReplyDelete
  28. Leif Uneus TMethod trick only does the job when you want to call a private method, but won't help you when you try to write/read a private field (I have a couple of cases like that myself). In that case, I think the best option is creating a shadow class (for Berlin, of course. Before that, a class helper is better).

    ReplyDelete
  29. Alexandre Machado Indeed, accessing private fields will be more cumbersome.

    ReplyDelete
  30. Ok, I added a way to get access to private fields as well.
    http://stackoverflow.com/a/37761852/576719
    With the help of a class helper and using RTTI only once at startup, it is possible to still have good performance accessing private fields.

    ReplyDelete
  31. Leif Uneus thanks for that. In short: With EMB changes we will do exactly what we were doing before: fixing bugs which the "code maintainer" is not able to fix himself - most of the cases "code maintainer" and Embarcadero are the same person. The difference is that now we have much more work to do it and the code will be really messy. GREAT! :-)

    ReplyDelete

Post a Comment