A long-term todo list

[slifeleaf]

Decided to post here to hear your opinion. This some kind of very long-term todo list (some of you may have read it already). It will be major time-saver to not spend time on some less wanted features.

• Replace an integer identifiers with enough long strings, maybe GUIDs or just randomize identifier generation (for security purposes)

• User-created JContainers contexts. Any user can get its own separate copy of JContainers. JC objects can not be transported across contexts. Purpose:

• • To make it possible to automatically remove a mod-specific JC-data when the mod gets de-installed. This is the optional feature. No special de-installation procedure needed, the mod-specific data won't be loaded during a save file loading.
    
  • Reduce cross-mod collisions. No-one will be able to erroneously clear your JDB or pick a range of object's identifiers and clear, release the objects.
    

  IDK whether it’s really useful to erase the data on uninstall.
  Example:

•  -- SomeCoolMod_JC_4.psc file is just a copy of standard API file (JContainers_4.psc),
   the copy is needed to redirect calls into SomeCoolMod's context
   Scriptname SomeCoolMod_JC_4
   
   -- somewhere in 'SomeCoolMod' code:
   import SomeCoolMod_JC_4
   -- or switch to the default context
   import JContainers_4
   
   int mapId = JMap_object()

• Merge Integer and Float into Number type. Internally stored as Double value. Still can be retrieved as a Real or Integer number with getInt, getFlt. For compatibility with Lua.
• Store Aliases? Under the hood is a pointer which consists of a quest and alias identifier
  
• Something else?

 

Misc. changes

• Rename JArray -> JList
• Boolean value type? 

JDB:

• add: getObj, removeKey
• mod: setObj(0) should not erase
• del: allKeys, writeToFile

JValue:

• move isList, isMap etc into JList, JMap etc - ex. JMap.eqType(object)

[jimka...@gmail.com]

I think these are very good ideas. I particularly like randomized identifiers and mod-specific contexts. I doubt that there are many, if any, mod author's who would purposely sabotage the data belonging to another mod. However, these changes will help reduce or eliminate the possibility that such a thing could happen unintentionally. 

Also, I'm not really certain what you mean about erasing the data on mod uninstall (this is related to contexts, right?), but I think its important to clean up the data when its no longer used. Perhaps add a function that a mod can call to delete everything associated with its own context, and let the mod author call the function as part of their own uninstall routine. This is just an idea, though, and may not be the best approach.

The other changes seem less important, to be honest. But I think that, as long as backwards-compatibility is preserved and the implementation remains efficient, there is no harm in making the changes.

Thanks for the work you are putting into this mod. I recently discovered it while trying to solve a problem in my own mod. Skyrim really lacks proper data structures, and this seems like an excellent solution to that deficiency. If I get my mod working, I'll message you with the details.

[slifeleaf]

Thanks for input

> Also, I'm not really certain what you mean about erasing the data on mod uninstall (this is related to contexts, right?), but I think its important to clean up the data when its no longer used. Perhaps add a function that a mod can call to delete everything associated with its own context, and let the mod author call the function as part of their own uninstall routine. This is just an idea, though, and may not be the best approach.

Yeah, this is related to the contexts and it's still important to cleanup the data. My idea is that a mod will put a file into some Contexts folder. The file is empty or may contain some settings. And, when a user will have uninstalled the mod (not via MCM, but will remove all the files or uncheck the mod in MO), the next time during a save file load the mod-related data will be skipped, will not be loaded. The settings may not allow JC to skip the data.

Though this feature may bring issues like unability to transport the data across contexts.

Either this will be implemented as the part of v3 API or it will turn into v4 API (and it'll be possible to install v4 alongside with v3)

Other features are mostly cosmetic changes

[Anthony Hubble]

Cleaning up mod JC data when that mod is uninstalled is a good idea, though I can see some cases where a mod is disabled by the user not because they want to get rid of it, but because they are testing for instability or incompatibility with other mods. Deleting the data assumes that the player doesn't want to install that mod again (though they can always go back to a previous save with the data intact I suppose).

Perhaps an ini file with various settings that the user can customise, including one to delete data from uninstalled mods (like the SKSE ini setting to delete orphaned script instances).

Being able to delete all of a mod's data with one call will save the mod author having to keep track of all the objects to delete on uninstall (I just put 99% of my objects into one hierarchical JDB structure so I just delete the parent to delete everything - but there may be a few that are missed as the mod grows over time).

[Anthony Hubble]

Re: Boolean data types - i just work around this by casting to or from an integer. If it's worth the effort, then why not :)

[slifeleaf]

Thanks for reply

There definitely must be some option for a dev or a user or both. It's not the problem to add missing functionality, the problem is that it's not possible to remove it (due to backward compatibility). Also note, that in v4 the calls like TypeName.functionCall will turn into "TypeName_functionCall", and there will be no nice highlighting (may reduce readability) - to not conflict with v3

[Anthony Hubble]

Re: function names, is it possible to just change the name of the scripts to JDB4, JMap4 etc but otherwise access the functions normally e.g. JMap.getObj() becomes JMap4.getObj() - would that do the same thing? Or will everything be going into the one .psc / .pex file?

[slifeleaf]

On Friday, May 1, 2015 at 2:40:57 AM UTC+3, Anthony Hubble wrote:

Re: function names, is it possible to just change the name of the scripts to JDB4, JMap4 etc but otherwise access the functions normally e.g. JMap.getObj() becomes JMap4.getObj() - would that do the same thing? Or will everything be going into the one .psc / .pex file?

It's possible to make the calls to default context look like JMapN.function(), though not possible for a user’s context (the plugin will create set of functions for each user's context and one default. the functions from the same context will share and target the context).

> Or will everything be going into the one .psc / .pex file?

That was my idea. The readability won't be affected as the source folder will still contain JC4_Array.psc.txt for documentation purposes