dunbarx wrote: ↑Thu Jul 18, 2024 4:49 pm
The property that I explicitly created and named (XYZ) changes its name all on its own, based on the name of a variable. Why does the property even look there? Something in the engine does that, I get it, but it seems an anomaly at least, and a bug as it stands.
Craig
As I said, I agree
this is incorrect behaviour but seems like the kind of thing that may be difficult to fix - and as the team are putting all their focus on LC10 and LC Create, so a fix may not be prioritised..
You could submit a bug report, that would not be wrong I don't think.
However the issue I raise is that
variable naming in LiveCode is actually important - as a typeless language that doesn't even require declarations to help the engine check these things fully, the onus falls in part onto the developer.
It's very tiring trying to read code where people thought they were being 'clever' my deliberately assigning 'funny' variable names. I mean I wouldn't call an array variable contain map coordinates DOGHOUSE or FFFFFF. That doesn't help anyone.
By using variable names that are clearly designated and named, we not only help ourselves code with fewer mistakes, but importantly the engine will behave as expected.
The above issue you found would be avoided if the developer used different naming conventions for handler/temp variables, script local variables, global variables and custom properties - usually the engine is clever enough to differentiate these in context even if developers may struggle.
But you found an instance where this does actually cause incorrect behaviour in the engine.
What do I know though, maybe it is easy to fix if the engine can differentiate
from
So maybe a bug report is worth it for correctness' sake. Or at the very least alert LC and fellow developers to this issue.
But I personally and many others who follow coding conventions wouldn't have been bitten by this.
I, as many others, prefix handler variables with "t", script local variables with "s", global variables with "g" and custom properties with "u" (although I know many use "c" instead).
That way there is no misunderstanding either by me or the engine
