2026/04/17
< 2026
|
Friday, April 17, 2026 (#107)
|
|
References |
Okay, it looks like it's time for some more notes...
Most of the previous 2 days has been sorting out how to apply the Parsing system to this problem, because it actually does seem like what I want.
I did briefly try to use sscanf(). Although it could probably do the job (and faster, albeit not noticeably so in this application), it doesn't quite work the way my brain wants it to and so this ends up being more confusing than helpful.
I also started using property hooks, mainly so I could do asymmetric visibility more gracefully. I haven't yet decided if this is a good idea, but for now there is one property using it.
- 10:03 (after updating the parsing system docs a bit) What I'm trying to do now is use that system for a task that's related to its design-purpose but is nonetheless new:
- Given the beginning of a template-string (Guide), determine if it matches the beginning of a found-string (Found).
- If it does, return the remaining parts of both strings, such that they can be used together to create another Gene-object.
- ...which can then use
Gene->MatchUp()to parse out the values in the Found string.
- ...which can then use
- 10:25 I wrote down my first action-thought on this, and then realized(?) that it's not really getting at the core of the problem. For the record:
I think what needs to happen is that Nucleus needs a little more separation of function:
- It currently stores both Guide and Found, although it doesn't actually do any parsing until
->Parse()is called.->Parse()splits up Guide and matches it up with Found.
- These should be two separate operations, and Found does not need to be stored.
- 10:38 My second thought is: why do we have a whole entire object for, basically, doing a single operation on a pair of strings, to produce another object which stores the results? Why doesn't that class do its own parsing operations?
- Was it really just the convenience of being able to store all the intermediate variables (string-fragments and position-pointers) while doing internal processing-function calls? If so, is that still a good reason? If that's so, maybe there's a better way to do it?