So I take what I said originally back, there is one case I can't account for with 100% accuracy for cast -> GUID which is using /targetnearest or /targetnearestfriend that targets a same named pet or vehicle with a cursor waiting for a target is up, as in /cast -> /targetnearest not /targetnearest -> /cast.
I think PendHeals.selfModifiers, PendHeals.healingModifiers, and PendHeals.healingStackMods should do lib.t = {}, instead of lib.t = lib.t or {}, so it upgrades properly.
Almost ready to tag this as beta and start having testing done, most of the comm code is in just need to go back and verify it all works. After that I'll write the wrapper to convert LibHealComm-3.0 data to LibPendingHeals-1.0 and an option to send healing data to LibHealComm-3.0 (Defaults to on, can be turned off with a function call).
I think PendHeals.selfModifiers, PendHeals.healingModifiers, and PendHeals.healingStackMods should do lib.t = {}, instead of lib.t = lib.t or {}, so it upgrades properly.
LibStub only creates one table per library/major version, when an upgrade is needed it passes the same table from r1 as you use in r5, so any tables set in r1 will still be there in r5.
LibStub only creates one table per library/major version, when an upgrade is needed it passes the same table from r1 as you use in r5, so any tables set in r1 will still be there in r5.
Yes, but how are new spellnames/spellids going to be added when upgrading? For example, if r1's healingModifiers has 10 spells and r5's healingModifiers has 20 spells, it won't get added the way it is now.
They'll just be added to the list through PendHeals.healingModifiers[blah] = true instead of through the table definition. Although, short of 4.0 I can't think of any spells I missed that self modify heals.
I'm not sure if you are confused or I'm confused on this :p
r1 loads, PendHeals table created, PendHeal.healingModifiers = {} created
r2 loads, PendHeals.healingModifiers is still there, new table isn't created because the old one is the latest reference.
r3 loads, PendHeals.healingModifiers is already defined, so a new entry is defined through PendHeals.healingModifiers[spellID] = 2.0
It doesn't have to upgrade the tables because the references are already there due to the table being reused from r1. Or are you saying if I change the table format in a major way it will work? I'm rather confused.
The second line above just uses the existing table if r1 was already loaded and LibStub returned the copy of MyLib created in r1 (the right side of the OR operator never gets executed). If r1 didn't exist, the table wouldn't exist and a new table is created.
The 3rd line then overwrites the data of 10 with 40.
Now say the following is r3, where 2 new spells got introduced.
Spells1-3 overwrite existing entries, spell4 and spell5 are added to the existing table. That's for upgrading data.
Similarly, if you had a function like this in r1
functiuon MyLib:Blah()
print("Blah")
end
If you then defined this in r2:
functiuon MyLib:Blah()
print("Bloop")
end
The redefined function MyLib.Blah in r2 would overwrite the one in r1 (MyLib is a table after all, and Blah is a table entry), and as long as you don't have a local reference to MyLib.Blah in the library, the version in r1 would become unreferenced and get GCed.
As such, for a library that takes in registration from addons using it, a table stores a list of addons embedding it usually in MyLib.embeds, when such a library upgrades, it iterates that list of addons and reembeds all the overwritten function references to GC the old references.
Shadowed and I have agreed to work together on this, to put our resources to best use, and cause the least amount of trouble for both developers and end users. This means the following:
1) LibPendingHeals-1.0 will be named LibHealComm-4.0.
2) Shadowed will be the lead designer, developer and maintainer of LHC-4.0, and will have full control of the project.
3) I will keep maintaining LHC-3.0, but no further development will be made to it, except for normal maintenance (patch breakage, spell updates, etc.), in the period until it is fully replaced by LHC-4.0.
We believe this is in the best interest of all parties, and hope that you all agree and support this decision.
The original wrapper library will still be done to make it easier for people to transition to 4.0, and xbeeps has permissions on 4.0 as well if he gets bored and wants to tweak around with this.
Now if I could find a mod to close this topic so I can do a new one and rename the slug URL again!
/targetlasttarget and such will work fine though.
Moved and updated all of the documentation, it can now be found at
http://www.wowace.com/addons/libpendingheals-1-0/pages/api/
LibStub only creates one table per library/major version, when an upgrade is needed it passes the same table from r1 as you use in r5, so any tables set in r1 will still be there in r5.
Yes, but how are new spellnames/spellids going to be added when upgrading? For example, if r1's healingModifiers has 10 spells and r5's healingModifiers has 20 spells, it won't get added the way it is now.
r1 loads, PendHeals table created, PendHeal.healingModifiers = {} created
r2 loads, PendHeals.healingModifiers is still there, new table isn't created because the old one is the latest reference.
r3 loads, PendHeals.healingModifiers is already defined, so a new entry is defined through PendHeals.healingModifiers[spellID] = 2.0
It doesn't have to upgrade the tables because the references are already there due to the table being reused from r1. Or are you saying if I change the table format in a major way it will work? I'm rather confused.
It's easy. Look at this code. Say this is r1:
MyLib = LibStub("MyLib-1.0", 1)
MyLib.Spellcoeffcients = MyLib.Spellcoeffcients or {}
MyLib.Spellcoeffcients["spell1"] = 10
MyLib.Spellcoeffcients["spell2"] = 20
MyLib.Spellcoeffcients["spell3"] = 30
Now say this is r2, where say spell1's coefficient got changed to 40:
MyLib = LibStub("MyLib-1.0", 2)
MyLib.Spellcoeffcients = MyLib.Spellcoeffcients or {}
MyLib.Spellcoeffcients["spell1"] = 40
MyLib.Spellcoeffcients["spell2"] = 20
MyLib.Spellcoeffcients["spell3"] = 30
The second line above just uses the existing table if r1 was already loaded and LibStub returned the copy of MyLib created in r1 (the right side of the OR operator never gets executed). If r1 didn't exist, the table wouldn't exist and a new table is created.
The 3rd line then overwrites the data of 10 with 40.
Now say the following is r3, where 2 new spells got introduced.
MyLib = LibStub("MyLib-1.0", 3)
MyLib.Spellcoeffcients = MyLib.Spellcoeffcients or {}
MyLib.Spellcoeffcients["spell1"] = 40
MyLib.Spellcoeffcients["spell2"] = 20
MyLib.Spellcoeffcients["spell3"] = 30
MyLib.Spellcoeffcients["spell4"] = 40
MyLib.Spellcoeffcients["spell5"] = 50
Spells1-3 overwrite existing entries, spell4 and spell5 are added to the existing table. That's for upgrading data.
Similarly, if you had a function like this in r1
functiuon MyLib:Blah()
print("Blah")
end
If you then defined this in r2:
functiuon MyLib:Blah()
print("Bloop")
end
The redefined function MyLib.Blah in r2 would overwrite the one in r1 (MyLib is a table after all, and Blah is a table entry), and as long as you don't have a local reference to MyLib.Blah in the library, the version in r1 would become unreferenced and get GCed.
As such, for a library that takes in registration from addons using it, a table stores a list of addons embedding it usually in MyLib.embeds, when such a library upgrades, it iterates that list of addons and reembeds all the overwritten function references to GC the old references.
1) LibPendingHeals-1.0 will be named LibHealComm-4.0.
2) Shadowed will be the lead designer, developer and maintainer of LHC-4.0, and will have full control of the project.
3) I will keep maintaining LHC-3.0, but no further development will be made to it, except for normal maintenance (patch breakage, spell updates, etc.), in the period until it is fully replaced by LHC-4.0.
We believe this is in the best interest of all parties, and hope that you all agree and support this decision.
Now if I could find a mod to close this topic so I can do a new one and rename the slug URL again!
All posts should be directed towards http://forums.wowace.com/showthread.php?t=16992 from now on, getting this locked.