Leaderboard

This has only been an issue if you make a mess out of your code design. In rare situations where you do need circular references using implementation section in one unit will suffice. I doubt that proposed changes would bring too much overall benefit and they would require extensive rework of the existing compiler architecture. There is existing feature which would be more beneficial for code organization: class helpers. Currently there is only a single supported helper in scope and having multiple ones would allow breaking down more complex code and organizing it into separate files. Implementing those would be a much simpler task, consistent with the existing architecture.

Smart Setup is a unified tool for installing and building Delphi packages, whether they come from TMS or elsewhere. See: https://www.tmssoftware.com/site/blog.asp?post=1360

Well, in this case you can. I did a lot of refactoring such code myself during the last decades. The constraint you suggested to remove is a good indicator of progress in such an endeavor.

Description: In Delphi, it's not possible to list units that reference each other in the interface uses section. This limitation significantly hinders class organization within a package. Initially, developers work around this by moving some unit references to the implementation uses section. However, as the class hierarchy becomes more complex, this strategy breaks down. At a certain point, class inheritance and cross-referencing between units can no longer evolve naturally due to circular reference restrictions. Instead of focusing on building a clean and scalable architecture, developers are forced to spend an excessive amount of time carefully juggling interface and implementation references across units to avoid dependency issues. Suggestion: Consider removing the concept of unit as a fundamental structural element in Delphi’s object model, and instead rely entirely on package-based architecture. Classes within the same package should be able to access each other regardless of which unit they reside in, without exposing their internal structure outside the package. If this change is too radical for Delphi’s current model, a more incremental alternative could be introduced: Allow splitting of interface/implementation code across multiple files, which could then be merged by the compiler or a preprocessor into a single internal unit. This would simulate package-level cohesion without breaking existing language design principles.

I enjoyed reading your contributions on SO and your blog posts on this topic, for example https://www.uweraabe.de/Blog/2010/08/16/the-visitor-pattern-part-2/ ("The Visitor Pattern – Part 2"), which I think are a essential reading:

You may as well just stuff all your classes into a single unit so you can achieve this. You don't need the language to undergo a fundamental redesign. As projects grow the issues with circular references can become annoying. I know this well. But the solution is to do better class design, not to embrace the excessive coupling of the classes.

On reflection, I will add your new prototypes to ICS. I was going to suggest you created your own import table with the RSA functions, similarly to the OpenSSL engine table that requires a define conditional to import. But ICS has a problem with the OpenSSL import tables getting larger as new functions are added, but old ones rarely disappear when they cease being used. So I'll create a new import table that will have most of the RSA_, ECDA_, DH_., EC_KEY_, EC_GROUP_ and DSA_ exports, with a new define around all those functions and the table, to ensure that none are currently being used by ICS. I already had to remove some EC_GROUP_ exports that have disappeared from some Linux distributions. Should be in SVN in a couple of days. Angus

The principle of a function that compares real values for equality, up to a specified tolerance, is a valid thing to do in many cases. But there are lots of caveats. In practise, most developers (and far from just in the Delphi space) that I see recommending it are completely unaware of these caveats. Some of these caveats and issues: How do you choose a tolerance? Does your tolerance account for the scale of the values, and indeed should it? Some use cases demand absolute tolerances, some demand relative tolerances. If you are accounting for scale, how do you choose the scale? Is it based on the pair of values being compared, or should it be based from the total pool of values. For instance, you might have two series that you wish to compare. Shouldn't the scale be based on the series rather than individual samples? Or maybe it is individual samples. It's easy to mistake this as an equality, but the resulting relationship implied by equality to tolerance is not transitive, so is not a mathematical equality. That is a R b and b R c does not imply a R c. Looking more specifically at Delphi's SameValue, the tolerance used when the Epsilon parameter is zero (or omitted) is very odd. I definitely think puppies are dying left, right and centre when that code path is chosen. One of the common misconceptions with floating point is that it is not exact. I think of it as exact, subject to the rules of the domain, but the key point is that not all values are representable. So if you have floating point values a and b, then they represent some precise real value. But when you do a * b, say, then the true value may not be representable. And so the result is the closest representable value. This is well defined, and reproducible. A lot of people think that there's just some random errors and fuzz in it all. That FuzzFactor constant in the RTL source seems to be a classic example of that sort of thinking. This famous question on SO is a useful resource: https://stackoverflow.com/questions/588004/is-floating-point-math-broken One of my pet bug bears in Delphi is its inability to convert correctly between floating point and textual representations. In every other mainstream language (and most non-mainstream languages) this is possible. But in Delphi the code used to perform these conversions is home grown and broken. There are good algorithms for doing this, and it's a subject of active research, but Embarcadero don't seem to care about this. In my codebase I use correct algorithms. Which means that for all values I can convert from float to text and back and always get the same value. The inability to do this often leads to users calling SameValue. My own codebase does call comparison function that compare for equality to tolerance. But there is a lot of care taken in how the tolerance is chosen and applied. I guess that's the crux of what I am saying. So many people just say, this is hard, slap a tolerance onto the comparison that is good enough for the two values I have to hand, and surely that's fine for all other values! I'm a bit of a pedant in this area, I admit. But it's kind of my job to be. Sorry!

Its a pity you won't be able to lets us know how many of all those requirements your final candidate actually has, when you find him of course. It would be quite interesting to see.

Last week-end I finished the rebuild in Delphi FMX of the video game Bidioo I've created in AGK Basic in 2013. It's a match-3 game. I used the sample match-3 TFrame added to Delphi FMX Game Snippets two weeks ago. The graphics are in SVG. I use Skia like in my other recent games. On iOS and macOS with Metal it's very speed. The best experience is of course on an iPad. On Windows without the Skia raster it works as expected (in a VM, I didn't check on a real PC). On Android it's too slow to have the full animations, but it works. I've to find the reason and check with Skia4Delphi and EMB teams if a solution can be found. The 2.0 version has been published on stores. you'll find the download links on this page. I can send you free coupons if you want to test the game on an Apple device. Just send me a private message. For Windows, use Itch to get the installer (and the game) for free. The source code of the project are on GitHub except some files where are stores the SVG (the images are under closed licenses). It won't compile as it instead of the match-3 sample project. Some demos are available from YouTube and PeerTube. If you want to talk about game programming in Delphi or this particular game, you know how to message me. We can do anythings in Delphi. Just try. 😉

https://docs.microsoft.com/en-us/windows/win32/api/objbase/nf-objbase-coinitialize And the documentation for CoInitializeEx states: