[quote=209513:@Norman Palardy]if as the code you posted so long ago does and sets MyClass, a class reference, to NIL you want
NIL.Operator_convert() as type to do what ?
Remember what its declared type is and call that things operator_convert ?
That could silently mask bugs or cause entirely new ones
It’s doing the right thing already and raising a nil object exception since you’re trying to invoke a method on a nil object which is nonsense[/quote]
I feel like we are going around in circles a bit here, but… basically “yes” - there is an argument to be made (by Myself, and at least one other Xojo denizen. Two makes a crowd!) that NIL.operator_convert() could be defined as “always NIL”, just like “NIL can be cast to anything” is allowed by the language, and there would be some benefits of that. I have yet to think of any bad consequences, but I’ve been programming long enough to not think that means there aren’t any…
Why did I start this thread? I was refactoring, thought of an obvious and “foolproof” change which was to use operator_convert(), and was rather surprised to see my code blowing up in about fifty different areas. “Principle of least surprise” was violated so I thought I’d bring it up for discussion.
Next topic: what is NAN/Inf ? 