Variables notation

[Rilgamon]

I've learned LUA from looking at working code and pick what
looks good to me.

Now I ran into a problem with what I thought to be right.

I thought

LibzzAddOnInit.AddOnTable.apps

is the same as

LibzzAddOnInit['AddOnTable']['apps']

I thought .AddOnTable and .apps would mean an extension to the local
variable LibzzAddOnInit and picked from local scope, too.

There are many examples and explanations using the dotted notation without making sure that the namecomponents was a local variable.

Now I got an errorreport that made me thinking. For one user the .apps part was set to nil but it was defined this way

LibzzAddOnInit.AddOnTable = LibzzAddOnInit.AddOnTable or {
  ['apps'] = {}
}

So it should never be possible to be nil. Or am I wrong ?
I did not find the reason. But changing to the other notation the error
is gone ... where is the fault in my thinking ?
[*] Bugreport : ProcWatch comments

[Foxlit]

LibzzAddOnInit = {AddOnTable={}};
LibzzAddOnInit.AddOnTable = LibzzAddOnInit.AddOnTable or {
  ['apps'] = {}
}
print(LibzzAddOnInit.AddOnTable.apps); -- nil

LibzzAddOnInit.AddOnTable.apps and LibzzAddOnInit['AddOnTable']['apps'] are indeed equivalent; it's just that your initialization does not necessarily create the apps key if AddOnTable isn't nil/false to begin with.

[Rilgamon]

local LibzzAddOnInit, oldminor = LibStub:NewLibrary(MAJOR, MINOR)

LibzzAddOnInit.AddOnTable = LibzzAddOnInit.AddOnTable or {
  ['title'] = 'LibzzAddOnInit',
  ['Debug'] = false,
  ['ConsoleColor'] = '444488',
  ['commPrefix'] = 'Libzz',
  ['iconSize'] = 14,
  ['apps'] = {}
}

This is the code used. And the first time the lib is loaded this should be
initialized I would guess ?

[nightcracker]

Make sure that the thing you are indexing is a table.

local corrupt = nil
corrupt.lol = 1 -- this generates an error
corrupt["lol"] = 1 -- this generates an error
 
local good = {}
good.lol = 1 -- yay, this works
good.lol.corrupt = 1 -- another error, because your indexing a number value

[Rilgamon]

Originally Posted by nightcracker Make sure that the thing you are indexing is a table. [highlight=lua]local corrupt = nil corrupt.lol = 1 -- this generates an error corrupt["lol"] = 1 -- this generates an error local good = {} good.lol = 1 -- yay, this works good.lol.corrupt = 1 -- another error, because your indexing a number value[/hightlight]

my prob is not the first var ... I mean the following. so in your example
'lol' and 'corrupt' and not 'good'.

[lilsparky]

look at the bug report. AddOnTable is an empty table.

AddOnTable = <table> { }

that's the basic problem...

[Saiket]

Did an older version of "Libzz" not include that apps sub-table? Your current code inherits the entire "AddOnTable" sub-table if it was already created by an older version of the library.

You could use the same technique for all your sub-tables too:

local LibzzAddOnInit, oldminor = LibStub:NewLibrary(MAJOR, MINOR)

LibzzAddOnInit.AddOnTable = LibzzAddOnInit.AddOnTable or {
  ['title'] = 'LibzzAddOnInit',
  ['Debug'] = false,
  ['ConsoleColor'] = '444488',
  ['commPrefix'] = 'Libzz',
  ['iconSize'] = 14,
}
LibzzAddOnInit.AddOnTable.apps = LibzzAddOnInit.AddOnTable.apps or {}

[Rilgamon]

Originally Posted by lilsparky look at the bug report. AddOnTable is an empty table. that's the basic problem...

Yes, but I just dont know how this could happen.
If it were nil ok, then I'd know why ... but an empty table
means it gets altered at somewhere ... and my guess its
changed in the global scope and not in my code ...

[Rilgamon]

Originally Posted by Saiket Did an older version of "Libzz" not include that apps sub-table? Your current code inherits the entire "AddOnTable" sub-table if it was already created by an older version of the library.

The apps part is one of the first things added in the lib. I even installed
all addons the user had ... but here I could not reproduce it.

[lilsparky]

you sure that was the only error he had? if something else bombed out, that table could have been left dangling.

[Rilgamon]

I provided him a version with the dotted notation replaced
and the error was gone but the addon still not working.
After replacing the older lib of the other addon of mine his
problem was gone and worked as it should.

Thats why I wonder how it's possible to get different results
when both notations should deliver the same.

And my guess it is changed in a global scope ...

[orionshock]

Originally Posted by Rilgamon I provided him a version with the dotted notation replaced and the error was gone but the addon still not working. After replacing the older lib of the other addon of mine his problem was gone and worked as it should. Thats why I wonder how it's possible to get different results when both notations should deliver the same. And my guess it is changed in a global scope ...

as Saiket said. it was an error in your lib upgrade path as your own explanation details.

When the other addon had and older version of the lib it didn't have the .apps sub table. Your primary addon had the update version of the lib that did.

Your code that you use dosn't account for upgrade paths correctly and thus the .apps subtable was missing after the upgrade.


LibzzAddOnInit.AddOnTable = LibzzAddOnInit.AddOnTable or {...}

^^ This code effectively translates to "Set this table key to itself if nil otherwise use this new table im declaring".

As your upgrading from one version of the lib to the next, the table already existed but from a version of the lib that didn't have the .apps key.

[Rilgamon]

Originally Posted by orionshock When the other addon had and older version of the lib it didn't have the .apps sub table. Your primary addon had the update version of the lib that did. Your code that you use dosn't account for upgrade paths correctly and thus the .apps subtable was missing after the upgrade. LibzzAddOnInit.AddOnTable = LibzzAddOnInit.AddOnTable or {...} ^^ This code effectively translates to "Set this table key to itself if nil otherwise use this new table im declaring". As your upgrading from one version of the lib to the next, the table already existed but from a version of the lib that didn't have the .apps key.

True.
I digged through all old versions of the lib and the oldest has only

LibzzAddOnInit.AddOnTable = LibzzAddOnInit.AddOnTable or {
  ['ConsoleColor'] = '444488',
}

So its my fault that apps is empty and throws the error. Still AddOnTable should never be {} and it should make no difference which notation I use.

But thanks for all the good ideas and tips ... That helps me to prevent this
in future. I'll rewrite the part so that every single value and table is checked to exist so that adding values in later versions is no problem

Additionally I'll stay away from dotted notation to make sure that when there is a problem that its from my code