Strange custom prop behavior

[dunbarx]

This was maddening.

One can set a custom prop to anything one wants. But one cannot set a custom prop to the contents of a variable with the same name:

Code: Select all

on mouseUp
put random(999) into temp

set the XYZ of me to temp  --works, XYZ contains a random number.

set the temp of me to temp -- NOPE!
end mouseup

A new custom prop, named with the value of the variable itself, is created, and contains (what else?) the value of the variable. At least LC got that part right.

Craig

[stam]

This was maddening.

One can set a custom prop to anything one wants. But one cannot set a custom prop to a variable with the same name:

Code: Select all

on mouseUp
put random(999) into temp

set the XYZ of me to temp  --works, XYZ contains a random number.

set the temp of me to temp -- NOPE!
end mouseup

A new custom prop, named with the value of the variable itself, is created, and contains (what else?) the value of the variable. At least LC got that part right.

Craig

Yes if you pass a variable with content, it uses that content as custom prop name, and you then also assign it's value to itself.
Strictly speaking this probably is incorrect behaviour because the "the temp of me" (custom prop) ≠ "temp" (local var).

Not sure it will be easy to address because that's probably tied to the fabric of custom props - but you can always raise a bug report if you feel strongly about this - but can't see this will be fixed really.

I would argue represents is very dangerous coding, very error prone, confusing to others reading your code or even to yourself when you come back to this 2 years later, and should be (strongly) discouraged....

The recommendations from all sites that make recommendation on coding styles is to prefix variables with a letter than indicates their scope - and for custom props the usual recommendation is to prefix the variable name with a "c" or a "u" - ie cTemp or uTemp.

I'm sure you know this......

[dunbarx]

Stam.

Thanks for the reply.

I'm sure you know this......

I do pay close attention to the usual, not naming controls with numbers, that sort of thing.

But I did not think that creating an explicitly named custom property, an entity with (I thought) a separate and solid existence of its own, would change its name just because a variable containing data to load into that property happened to have the property name. I thought I was being compact, in that if I read this again in a month both "halves" of that statement (the property and the variable) would be related and make sense.

Code: Select all

set the XYZ of me to xyz

So again, the property that I explicitly created and named (XYZ) changes its name all on its own, based on the name of a variable, and the new name is, wait for it, the %^$#&^ contents of that variable. Why that, and 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

[dunbarx]

Stam.

I am not going to post a bug report, since I now simply know what to avoid. Maybe this might help someone else.

Craig

[stam]

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

Code: Select all

the <variableName> of <object>

from

Code: Select all

local <variableName>

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

[dunbarx]

Stam.

Everything you say is correct.

I wouldn't call an array variable contain map coordinates DOGHOUSE or FFFFFF

With all CAPS, only Richmond would do that
I do prefix handler variables with "t". I just didn't in this case because I was quick-testing some side routines, and was lazy. Just another instance of being lazy causing me to waste time.

Craig

[bwmilby]

This was maddening.

One can set a custom prop to anything one wants. But one cannot set a custom prop to the contents of a variable with the same name:

Code: Select all

snip

A new custom prop, named with the value of the variable itself, is created, and contains (what else?) the value of the variable. At least LC got that part right.

Craig

It isn't strange at all. It is the expected behavior. This is what you want:

Code: Select all

on mouseUp
   put random(999) into temp

   set the XYZ of me to temp  --works, XYZ contains a random number.

   set the temp of me to temp -- NOPE!
   set the "temp" of me to temp -- corrected
end mouseup

When an unquoted literal is encountered, it is assumed to be the literal. If it is a variable name, then the value is used. It behaves that way throughout the language.

[stam]

Thanks for clarifying Brian.
Food for thought and caution…

[richmond62]

with all caps . . .

are you sure?

love, richmond.

[dunbarx]

Yes.

Brian found a (not-so-hidden) flaw in my thinking. Though I had no unquoted literals, LC resolves "set the temp of me..." to "set the (contents of temp) of me..."

As it should.

Thanks for reminding me how xTalks work. I should have put this in the beginners section.

Craig