Thank you, @careyh. It just goes to show how little I understand of the inner workings of Komodo that it didn’t even occur to me that it being 32-bit or 64-bit would have an effect. So more than likely, if I were running 64-bit Komodo, then the assert() statements would work as expected? If so, then at some point in the future I could simply switch to 64-bit Komodo and do the same for PHP.
I had to go back through the original Github issue to review. I think the more likely issue is that something changed in Xdebug that compiles for PHP >= 7.3 that cause Komodo to skip assert statements. Honestly, now that I think about it again I could see this being a feature. Having assert() statements while you’re debugging is redundant, no? You can see the variables state in the debugger, the assert() statement isn’t helping you.
FYI, what Komodo is actually compiled with is extreeeeeeemely unlikely to effect things like PHP or Xdebug. All three of those tools run as separate processes and communicate through either TCP or msg passing through sub processes, neither of which should be effected by the bit size things were compiled at.
Thanks for the clarification regarding the impact of what Komodo is compiled in versus PHP and Xdebug.
While it is true that we can see the current values of variables in the debugger, that all requires manual stepping in the debugger and checking values. But in the service of automating that process, assert() statements are essential parts of unit test functions. In fact, all my unit test functions consist of mostly assert() statements. Any time I make a change to a function, I rerun the corresponding unit test function to verify that I have not broken anything. Also, in a matter of seconds it can run hundreds of unit test functions (one for each of the functions in my libraries) to verify that nothing has broken over time.
@mjross, it sounds like you think I’m saying to remove the assert() statements. I’m not at all. I’m saying that Xdebug is POSSIBLY skipping them on purpose because it’s redundant to hit an assert statement WHILE debugging. All your points about the goodness of assert are true and you should totally use them.
ie. if we figure this out, it might end up being a feature, not a bug. I wouldn’t be surprised if it was an option that was turned ON in a recent version of Xdebug.
I see. Thank you for the further clarification. Yes, I started writing unit test functions decades ago, and now I can’t imagine not using them.
From my perspective, if this turns out to be a purposeful change, then I would not consider it to be a feature, as reflected in my earlier bug report:
Debug stepping (both Debug > Step In and Debug > Step Over) jumps over all assert() statements, regardless whether the values they test are true or false, and even assert() statements that call other functions, thereby preventing me from stepping into those called functions. If I step into a function that consists of assert() statements only, then the Debugger jumps straight to the end of the function.