Using value of Variable

[[-hh]]

..........

[[-hh]]

..........

[FourthWorld]

First of all:
I was told from a friend to be more sensitive with my wording, it seems, my post came over to be a bit 'rough'. Sorry you all, I didn't want to be snotnosed and I hope and feel from your answer, that you (Richard) didn't take it in such a 'wrong way'. My post became 'insensitive' because I wanted to write shortly 'the facts'.

I appreciate your sensitivity, but it's that very sensitivity that suggests you have nothing to worry about. No offense taken here; on the contrary, good testing benefits from accounting for as many details as practical, and you raised a very relevant observation.

In fact, this is exactly the sort of thing we hope to see with IDE fixes and other things throughout the community. Like Linus says, "Given enough eyeballs, all bugs are shallow."

After a night's sleep I figured out a simpler way for me to at least somewhat reduce the overhead of the strings by just shortening them, replacing line 12 in the original script:

Code: Select all

create btn "SomeButton"& i

...with:

Code: Select all

create btn "S"& i

Of course this means that strings will always still be longer than the ordinal number, but only by one character, and in all cases below 1000 shorter than IDs.

Running the original script this morning (worth re-running because I've been running VMs in the meantime so memory is potentially impaired - thanks OS X <g>) gives me:

Names: 154
IDs: 42
Ordinals: 37
true true

After shortening the name prefix from "SomeButton" to "S" I get:

Names: 114
IDs: 41
Ordinals: 34
true true

The differences between the unchanged methods (IDs and Ordinals) is accountable by the many things that make testing challenging, namely background processes, heap shifting, etc.

But the difference in the Names value definitely shows improvement with the shorter name, providing a second validation for your hypothesis in addition to your earlier test on the delta.

[[-hh]]

..........

[dunbarx]

Hermann.

Confirmed here.

Odd that the reference is valid in some ways, but not in others. A bug? Or just a limitation that should be included in the dictionary?

Craig

[[-hh]]

..........

[dunbarx]

Hermann.

But this works:

Code: Select all

put "Hello" into field (the name of fld 1)  --fld 1 is  fld "4.2"

But then I tried all sorts of "do" constructions, figuring I could make that work, like:

Code: Select all

do "put hello into field" && "4.2"

and they all fail.

Craig

[bn]

Hermann,

this works also

Code: Select all

on mouseUp
   put quote & "4,2" & quote into tField
   put "Hello Hermann" into field the value of tField
end mouseUp

but maybe similar restrictions as for variable names apply?

The names of variables must consist of a single word and may contain any combination of letters, digits, and underscores (_). The first character must be either a letter or an underscore. You cannot use any LiveCode language word as a name of a variable.

Kind regards
Bernd


EDIT: I accidentally used "4,2" instead of "4.2".
Above workaraound does NOT work with "4.2".

[mwieder]

Hermann-

Re: non-integer "numbering", no, the problem is with being able to create an exact copy of a control *including the id*. This is getting way off-topic here, but for version control you need to be able to store a representation of an object that allows you to recreate it in its original form.

To get this back on topic, if an object is being referenced by its id then it is essential to be able to set the id of the object to its original value when it is recreated. Referencing an object in other ways helps mitigate the problem, but not entirely since there are some forms of referring to objects (behaviors, etc) that require the use of the id property.

[mwieder]

I think this is a bug when using quotes around the 'number', because there is no possible conflict with ordinal (integer) numbers or ids. This must work: put "Hello" into fld "4.2"!

I do think of this as a bug, but it's a historical artifact. The original xtalk language specification allowed users to do without quotes around strings. I've never liked this "helpful" feature, but it's something we're stuck with. With this in mind,

fld 4.2
and
fld "42"

are the same thing to the engine as it parses incoming text.

So yes, I do think that should work, and no, it's not going to work the way we'd like it to.

[FourthWorld]

Not being able to use numbers for names makes a certain amount of sense given that the syntax for each is the same:

Code: Select all

get the text of btn 1
get the text of btn Steve
put 1 into tVar
get the text of btn tVar
put Steve into tVar
get the text of btn tVar

One could argue (rightfully, I feel) that a fractional number can't make sense as an object ordinal number because objects are always whole things, so ordinal expressions should only use integers, perhaps allowing fractional numbers to be evaluated as a name.

But then try to explain to newcomers why some numbers are acceptable as names and some aren't.

Perhaps one way to handle this would be to be able to explicitly tell the engine how you're referring to an object, e.g.:

Code: Select all

get the text of btn number tVar
get the text of btn named tVar

But as it is, with the syntax for ordinals and names being the same, apparently the engine checks if the value is a number and if so attempts an ordinal evaluation.

[bn]

To add to Richard's comment:

if you do name one field "4.2" as field 1 and add 3 more fields to the card (unnamed fields)

and

Code: Select all

on mouseUp
   put "4.2" into tField
   put "Hello Hermann" into field  tField
end mouseUp

it puts "Hello Hermann" into field 4

BUT
if you say in the same setup

Code: Select all

on mouseUp
   put "4.9" into tField
   put "Hello Hermann" into field  tField
end mouseUp

it will fail.
So there seems to be first an evaluation if a field "4.2" exists and then when addressing the field it will use 4.2 as ordinal 4

Kind regards
Bernd