Re: Switch question - yet again!
- Posted by ghaberek (admin) Nov 16, 2022
- 8665 views
It is clear none of us has the time/ability combination to fix the innumerable problems with attaching destructors to atoms. Euphoria 4.0 went fast for adding new features and whenever you do so defects get introduced along with features. Some might have the ability to track down this bug but apparently not the time (inclination). Others may have lots of time and want to but not the ability.
This has definitely been the case with me. It's taken literally years to get up to speed on the internals of Euphoria and start adding or fixing things.
The first two are avoided because there are all kinds of corner cases that bite you. Putting an uninitialized object into object() is totally unneeded when you can have dummy values. It sometimes takes years before someone notices a bug that gets introduced. So, I tend to use the features that have been around longer rather than the newer stuff. I have never had a problem with the flow control statements. These seem rock solid.
Euphoria MVC makes heavy use of maps which it turns out didn't release from std/eumem.e correctly depending on how I passed them around. I ended up writing mvc/mapdbg.e to track this down so an app running in the development web server wouldn't run out of memory so quickly. I also use switch a lot and have never run into the issue but I can't say I've ever assigned a destructor to a constant. It seems irrelevant to do so but it still shouldn't cause an issue.
Library routines are different because they run on top of the front end and generally keep with my avoid list above. However, I don't use std/http.e because it is and has always been obsolete. We were already with HTTPS everywhere when someone added it. If you need to transfer over the internet, use curl.
I'm planning bundle a libcurl wrapper with Euphoria 4.2 (including DLLs on on Windows and rely on system libcurl on *nix). I originally planned to then rebuild std/net/http.e as a wrapper for CURL but after working on FFI I'm thinking I'll just mark std/net/http.e routines as deprecate and leave it at that.
With ifdef you can perfectly check for platforms that don't exist or are misspelled or of the wrong case. This results in hours lost because of a typo in debugging. It's like the macro processor for C except far more primitive.
I wonder if we should adapt this feature to contain table of all potential standard ifdef conditions that start at "off" and get flipped to "on" accordingly. Then we could add a warning for unrecognized conditions. Even add a similarity matching for unknown conditions. Something like "skipping unknown ifdef condition BITS34. did you mean BITS32?" And for truly optional conditions, you could also add without warning += ifdef CONDITION to avoid unnecessary "unknown ifdef CONDITION."
Lastly, because I mostly write in Node/C plus plus/Java, a lot of the habits I learned in these languages become part of my coding style. Therefore, I think the same is true for most people. So using a non-literal as a case value is something probably none of the development team ever tried. So that's another reasons this bug would exist.
We should ensure Euphoria isn't a language that causes too much friction for folks coming from other languages or using several languages at once. So far I think we've done a good job of that but it's important to keep in mind as we make changes. In this case, constants should be constant and releasing a constant before the end of the program should cause a big red flag. But the backend doesn't check the symbol table for an object's scope during a cleanup. Maybe it should if it's not too much work and won't a performance hit? It would only need to be for user-defined cleanups not all dereferencing in general.
-Greg
