Config API Extension Suggestion

9 views
Skip to first unread message

enobayram

unread,
Nov 12, 2015, 12:16:17 AM11/12/15
to orx-dev
I think these two config functions would be useful:
1) orxU32 orxConfig_GetValueID(orxU32 keyID): This function returns the string id of the raw string value corresponding to the key with the string id "keyID"
2) orxU32 orxConfig_GetSectionVersion(orxU32 sectionID): This function returns a version number for the given Config section (indicated by its string id). Whenever any key in the section changes, or new keys are added/removed the returned version is incremented.

Motivation:
These two functions could be very useful for caching stuff. For instance, if we implement the text markup feature, the markup will need to be parsed every time the String changes, but we don't want to parse it again if the String is the same. With function (1) above, we could invalidate the cached parse-tree whenever the value for the "String" key changes.

The second function could be useful for caching expensive-to-calculate data structures that depend on the entire section.

orx-project

unread,
Nov 12, 2015, 12:48:32 AM11/12/15
to orx...@googlegroups.com
Why not going with an event in that case?

Also, the current API uses strings as parameters and passing IDs would be inconsistent. That being said, I'd like a new version of the API that only works with IDs for efficiency, but I'd like to find a way to not have to duplicate everything.

--
You received this message because you are subscribed to the Google Groups "orx-dev" group.
To post to this group, send email to orx...@googlegroups.com.
Visit this group at http://groups.google.com/group/orx-dev.

Enis BAYRAMOĞLU

unread,
Nov 12, 2015, 1:10:57 AM11/12/15
to orx...@googlegroups.com
Why not going with an event in that case?
What event?  Is there an event thrown when a config value is changed?

Also, the current API uses strings as parameters and passing IDs would be inconsistent. That being said, I'd like a new version of the API that only works with IDs for efficiency, but I'd like to find a way to not have to duplicate everything.
Yes, that would be useful, but there's a lot to duplicate. 

iar...@orx-project.org

unread,
Nov 13, 2015, 12:12:02 AM11/13/15
to orx...@googlegroups.com
Why not going with an event in that case?
What event?  Is there an event thrown when a config value is changed?

There's no event yet, but one can be added.
 
Also, the current API uses strings as parameters and passing IDs would be inconsistent. That being said, I'd like a new version of the API that only works with IDs for efficiency, but I'd like to find a way to not have to duplicate everything.
Yes, that would be useful, but there's a lot to duplicate. 

I'd like to find a way to prevent the whole duplication without looking too hacky. We'll see!

Enis BAYRAMOĞLU

unread,
Nov 13, 2015, 1:39:14 AM11/13/15
to orx...@googlegroups.com
There's no event yet, but one can be added.
Wouldn't that cripple performance though? Considering how often you won't need it and how often one might be working with Config.

What is the performance implication of orxConfig_GetValueID(keyID) BTW, do you already have the valueID handy somewhere, or does it need to be calculated from the string every time? Actually, now that I think of it, the raw value string (I mean the value of the const char *, not the contents) could be used for cache validation just as well as the ID, since all strings returned by orxConfig are permanent :)

I'd like to find a way to prevent the whole duplication without looking too hacky. We'll see!
Which duplication concerns you more? Code duplication or interface duplication? Because, I guess you could easily write a macro to produce both versions from a single definition.

BTW, inspired from the previous comment about const char * being enough, do you think we could somehow speed-up the config section look-up when the user passes a permanent string obtained from orxString_GetFromID, removing the need for the second set of config Get functions in the first place?
Reply all
Reply to author
Forward
0 new messages