This is a bit nit picky but I’m a nit picker from way back!
I aways strive to code such that autocomplete does not get out of control and is more helpful (autocomplete lists don’t get too long and things are logically organized in categories and sub categories when needed)
And at the same time I like to keep the length of items as short as possible while maintaining readability.
Being able to use EndOfLine and a qualified version of it such as EndofLine.Windows in code follows those principles…
I use a certain plugin occasionally (so I never remember details) that has a whole bunch of various purpose constants on a top level module… So many that autocomplete is useless for finding things if you don’t remember the start of the item name .
So I am trying to create my own module to group them in submodules by category to make the plugin easier to use.
One of the categories in my supporting module is fonts which I have organized like this:
PM (module for that plugin)
Font ( category of items module)
Arial (module for things specific to this font )
Plain (Constant with info for plain version)
Bold (Constant with info for bold version)
Italic (Constant with info for italic version)
BoldItalic (Constant with info for bold italic version)
That way when I need a font for that plugin in code I can type (with autocomplete help) for example PM.Font.Arial.Bold
But analogous to EndOfLine, for the plain font variant instead of using: PM.Font.Arial.Plain
I would like to use just: PM.Font.Arial
But still be able to use: PM.Font.Arial.Bold
However adding a method, property or constant named Arial to PM.Font that returns the value causes issues.
The compiler can’t figure out the difference between a method or property or constant and a module at the same level with the same name in code. (it should be possible from context as a module can’t be assigned , but the compiler is just not written to do that)
So is there a way with this type of organization to get the same type of behavior one gets for EndOfLine in this case?
EndOfLine is implemented a bit different than you may think:
EndOfLine is a class.
And there is a global “EndOfLine as EndOfLine” function.
So when you ask it for it’s string, you call Operator_Convert on it to give you the string for the version you need. Also it has those functions for each platform, so you can query Windows, Linux, macOS or iOS variants.
Anyway, you could have a PM Module, inside a Font Module and there an Arial property giving some kind of FontFamily object. And that could have properties for the Fonts as well as a Operator_Convert for the default font.
You are certainly not talking about DynaPDFMBS as it’s 1200 constants are all easy to remember.
Not that many entries on CDBaseChartMBS compared to DynaPDF, but still WAY too many for a popup menu!!! (fonts are the least of the issues - and they are not at all on the autocomplete on it - but the things that are though, need grouping IMO!)
I understand your solution and could do that, but thinking about it, it’s not worth the effort/overhead just to not have to use PM.Font.FontName.Plain
Unfortunately your plugin does not implement everything the same way as it was done for ColdFusion, so when there are mismatches I search your PDF for the equivalent after I find it in those docs.
Docs like that which are specific to the xojo plugin would be great, but I know it likely is not something you could afford to do as it would b a big job and might not help sales.
