All about EndOfLine
Did you know there is an EndOfLine class in Xojo? You like a proof? Just run this code in a new project:
Now you see the object in the debugger. This is of course an implementation detail and could change.
When you use EndOfLine in the code as value and not as class, you call a global function called EndOfLine returning the EndOfLine object. This is optimized and we can verify in the debugger that we get the same object each time. If you use it in a string operation, it may invoke one of the operator methods like Operator_Convert to get the string for the current platform.
The individual functions Android, LF, iOS, CR, Unix, macOS, CRLF, Windows are shared methods (or properties?) on the class. Update: Introspection shows those are shared properties, but computed. And they seem to be implemented differently, so some return the same string always, while others just create a new string each time.
Due to the fact that using EndOfLine invokes two functions to get the object and then the string, it makes sense to cache the value. A line like this may speed up access to EndOfLine :
Following access is at least double the speed, so if that is a bottleneck for you, you can optimize it!
But only worth it, if you call EndOfLine a lot in loops within your code.
Wishes on Feedback
Looking into EndOfLine reminds me to two feature requests, I'd like to see implemented in a future Xojo version. Beside with EndOfLine, they could help us for our own code. All those shared properties could be real properties for the compiler, which could be marked to be read only for access from outside. For example a module could define them and in a Constructor for the module they could be assigned. So we need a kind of constructor for modules like in feedback case 24018. The constructor may only access things in the module and should be called before app.open. The properties could have an attribute to mark them public to get, but private to set. Like the idea in feedback case 49428. If this would be implemented, you could skip all those getter functions and the compiler could make much better code to just lookup the global EndOfLine property easier and skip it for the shared properties.
Let's say we would get those implemented and we could have a module like this:
As said, constructors should be run before App.Open and prepare the module. The compiler would assemble list of modules and call Constructor methods if those exist. Per definition access to other framework methods is possible, but not to other modules as order of initialization would not be defined. Although compiler could sort module names of course and then order is defined!
Finally there is also a Text.EndOfLine global function, which returns you EndOfLine as Text data type. But be aware, that on iOS Text.EndOfLine and EndOfLine.IOS don't return the same result. One returns Chr(13) and one Chr(10).