User Tools

Site Tools


pcb:preferences_subsystem

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
pcb:preferences_subsystem [2020/12/31 12:34]
cparker
pcb:preferences_subsystem [2021/02/28 19:56] (current)
cparker [Development Blog]
Line 336: Line 336:
 When a subsystem wants to inherit something, it should be familiar with what it's parent'​s attributes are and just grab those attributes directly. It should only store locally things that are specific to the subsystem. ​ When a subsystem wants to inherit something, it should be familiar with what it's parent'​s attributes are and just grab those attributes directly. It should only store locally things that are specific to the subsystem. ​
  
-But what if we passed a command-line parameter for a subsystem? The core won't know what to do with it because it's not in the core's list. We want that to be accessible to the subsystem, however. Maybe this is a good argument for the intermediate key/value pair structure. Perhaps we treat command-line arguments differently,​ and just save those vectors globally so that subsystems can inspect them at their leisure. ​+But what if we passed a command-line parameter for a subsystem? The core won't know what to do with it because it's not in the core's list. We want that to be accessible to the subsystem, however. Maybe this is a good argument for the intermediate key/value pair structure. Perhaps we treat command-line arguments differently,​ and just save those vectors globally so that subsystems can inspect them at their leisure.
  
 += 20210214 =
 +
 +In spite of keeping this blog for the purpose of remembering where I am... I've completely forgotten. I recall that I had started failing tests, and so I was rebuilding the system in a new branch to try to figure out where things went wrong. I guess I'm going to start getting back into this by bringing one class at a time into the new branch.
 +
 +Starting from master, I've added the PreferenceValue,​ PreferencePair,​ and preference cstring converters to the new base. This includes all of the tests, which pass.
 +
 +The next steps are to bring back in the apply functions, the parsing functions, and the file IO functions.
 +
 +One further note: support for PreferenceString isn't yet complete. There aren't converters for it, and it's not integrated with the reading and writing. The purpose of this data type is to allow arbitrary data to be stored in the files. Handling this type will require adding support for things like escape characters so that newlines and things can be included in the data. Right now I know that there'​s no arbitrary data that needs to be stored, so, I'm going to proceed without fully completing this, but, I probably need to add more remarks in the code about it.
 +
 += 20210228 = 
 +
 +As per usual, since I didn't have things completely laid out before-hand,​ I've made a bit of a mistake. I added a type enum to the PreferenceValue objects, however, these objects were supposed to point to the value in the preference structure, not actually contain the value themselves. It's probably still useful to have this type defined, but, not quite as useful as I had thought it would be.
 +
 +Now I've also created a PreferenceAlias type that is just a union of the different pref options. This will serve the purpose I had originally intended for PreferenceValue.
 +
 +The PreferenceDefinition type has been brought back into the fold, and all the tests now pass. This was a little tricky because I had to change a bunch of return values to PreferenceValue from char * in order to keep things more generic.
 +
 +All of the existing code has now been brought back into the codebase, and everything is passing its tests!
 +
 +Next steps are to figure out how to make this system handle command line arguments.
pcb/preferences_subsystem.1609436059.txt.gz ยท Last modified: 2020/12/31 12:34 by cparker