[SOLVED]Two possibly related bugs with variables

Posted on
Sun Jan 26, 2014 12:13 pm
wikner offline
Posts: 181
Joined: Nov 02, 2003

[SOLVED]Two possibly related bugs with variables

#1: The dependencies test does not seem to work in this particular case. I have a variable named "test_result" which is set in a trigger action from the state of a z-wave module. The following image shows that when I right-click on the variable and check for dependencies, I am informed that there are none.
Image
The next image shows that the variable is, in fact, set in the trigger action. The image also illustrates...
#2 The display within the GUI of device ID's instead of device names and variable ID's instead of variable names. You might argue that this is a feature, not a bug, but I it is at least a serious mis-feature. It reminds me of the late 1960's when I had to keep track of the numerical memory locations of my variables when programming. Later we got compilers which introduced the freedom of keeping track of variables by variable names. This was a marked improvement. Having to use and keep track of these ID numbers in Indigo seems like a 50-year throwback.
Image

Posted on
Sun Jan 26, 2014 12:55 pm
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

Re: Two possibly related bugs with variables

The images you posted aren't visible/available.

Image


Posted on
Mon Jan 27, 2014 5:52 pm
jay (support) offline
Site Admin
User avatar
Posts: 18200
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Two possibly related bugs with variables

Plugins that use ID's are not included in the dependency search because the server doesn't know that a plugin is using a particular object - that's outside of what the server knows when it looks up what things use any given object. We have an item on our todo list to allow plugins to register/unregister an object with the server if it's using that object but that has yet to be done (and would require that developers actually implement the registration - it's not possible to do automatically). We understand that it is somewhat confusing because we've implemented several of the new actions in an internal plugin but they appear integrated in the action selection hierarchy.

As for IDs - it is common practice to use an immutable (unchangeable) identifier for an object (such as an ID) when you're dealing with a database. Names can change (are mutable) but an ID stays the same for the life of the object. Why? Because you never know what things outside of the database are referencing objects in the database. We present many opportunities for users and developers to use Indigo objects: in external scripts, in API calls, etc. If we allowed only the use of the name of an object (which can change at any time) it would be nearly impossible for those things to know and they would break.

You'll notice that you weren't required to type in the ID in the dialog that defines the action - we present a list of variable names. We show the ID in the summary of the action because we don't store the name of the variable (because it can change), but rather we store the ID. When that dialog opens, we don't query the database to look up the name for that ID because it's unnecessary unless you're specifically trying to change it. If that's the case, you can just click on the "Edit Action Settings…" button and it will perform the lookup and show you the name.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Mon Jan 27, 2014 8:31 pm
wikner offline
Posts: 181
Joined: Nov 02, 2003

Re: Two possibly related bugs with variables

So how was I to know that the GUI feature that I was using was part of a plugin? And what will happen when I delete the variable in question, as I was about to do? I recon that the "immutable" nature of a variable doesn't survive deletion of the variable. I

As to a discussion of the proper implementation of databases and the use of id's for indexing and referencing, I'll only say that one should rarely, or preferably never, make the user of a database need to know or even be aware of these ID's. For the user, only names are meaningful. If the user chooses to change the name of an object in a database, that change should be reflected throughout the user's experience of the database with the name looked up and presented to the user wherever it is relevant. If it is necessary for names to be unique (as it would often be in Indigo), then the user should be warned and/or prevented from changing a name to that of an existing name or from creating a name that is a duplicate. If necessary some sort of namespace qualification (like Python's dot notation) should be implemented to make similar names unique.

As a programmer, I am perfectly willing to accept the consequences or renaming a variable as long as: 1) the compiler/interpreter either changes the name for me throughout my code or 2) I can do a global search-and-replace on the name throughout my code. Failing that I would even rather get errors and figure out that they have resulted from an name change (as I will have to do, for example when I switch from WeatherD to WeatherSnoop and all my weather variables, which are extensively referenced throughout AppleScript code, change their names) than to have to manually keep or reference a lookup table of variable IDs.

Posted on
Tue Jan 28, 2014 10:23 am
jay (support) offline
Site Admin
User avatar
Posts: 18200
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Two possibly related bugs with variables

You weren't supposed to know - that's why I explained it in the first paragraph. After looking at the docs for the dependency dialog I realized we forgot to note the exceptions - we'll get that updated. As I described, getting dependencies for plugins is going to be tricky and we couldn't address it in Indigo 6 - however, we thought having some dependencies easily visible was better than no dependencies visible (as was the case with Indigo 5). No excuses, just the facts.

As a programmer, you may prefer outright failures rather than allowing users to avoid failures by exposing ID's in some places. We believe that our users are intelligent enough to handle the concept of an ID - and in the few cases where we require users to directly use them (rather than pick from lists/menus) we believe the tradeoff to avoid future breakage was a better option. It's a design choice based on our understanding of customers' abilities in our target market. And we know our target market pretty well.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Jan 28, 2014 8:13 pm
wikner offline
Posts: 181
Joined: Nov 02, 2003

Re: Two possibly related bugs with variables

Ok, ok. I give. I can always do the lookups myself. Truth to tell, I always code variable names by cutting and pasting so I won't misspell them; I can just as easily cut and paste ID's and then enforce a rule for myself that I will always add a comment to my code indicating what variable name the ID refers to.

But I still have the question. What will happen to my trigger event if I delete the variable to which it refers? Shall I just do the experiment or will the next execution of the trigger crash the server?

Posted on
Tue Jan 28, 2014 8:37 pm
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

Re: Two possibly related bugs with variables

It should fail gracefully, likely will log an error in the Event Log. We will improve the dependency checking, but have quite a bit on our plates so no ETA.

Image

Posted on
Tue Jan 28, 2014 8:53 pm
jay (support) offline
Site Admin
User avatar
Posts: 18200
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Two possibly related bugs with variables

If you right click on an object in indigo one option is to copy a python reference - that will put the code to get the object along with the name in a comment after it - so no extra typing at least in that scenario. ;)

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Wed Jan 29, 2014 10:23 am
jay (support) offline
Site Admin
User avatar
Posts: 18200
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Two possibly related bugs with variables

One other feature: in the Python embedded script editor, if you select an ID and right-click it you'll see the corresponding object name in the popup. For variables it will just show the name, for other object types you can actually open the edit dialog for the object from the menu item.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Wed Jan 29, 2014 11:24 am
wikner offline
Posts: 181
Joined: Nov 02, 2003

Re: Two possibly related bugs with variables

Those are two very nice features of which I was unaware. Thank you.

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 1 guest