2026/03/02

Monday, March 2, 2026 (#61)

Sunday Monday Tuesday posts: prev < this > next

The next puzzle-piece to work out is where to re-insert the error-handling code. I think the way I had it before, it was in the Client (formerly Oper) near the end of DoCommand() (or maybe it was in the action-requests?), and what is now [WFe]Sys\Events\MsgsOp was then an ItWent-podling, and that is what got returned from DoCommand(). I'm not sure if that means the error information was included or if it just got displayed on the screen (there was a function called HandleResults(), iirc... ahh, ok, that still exists, but I'm not using it consistently.

...and also, it only works if the messages are in the ItWent which gets passed to it, and I don't think that's happening. Is that still the way to do it? Maybe...

My first thought was to get rid of [WFe]Sys\Data\Engine\aux\msgs\Maria\Ops and [WFe]Sys\Data\Engine\aux\msgs\MySQL\Ops, but those each define (in ErrorsAdminClass()) which [WFe]Sys\Events\Message\Errors class to use, and that itself is necessary. Maybe ErrorsAdminClass() should be in the Client instead?

Code changes:

1. ErrorsAdminClass() is now defined/required in Client, and named MessagesClass()

2. I'm commenting out MsgsOp() and MsgsOpClass().

I want to rename [WFe]Sys\Events\Message\Errors to something more general -- it can in theory handle messages that aren't errors -- but not sure what to call it. The key difference between the Message (singular) base-class and what is now Errors seems to be that the latter is for correctly identifying received messages, while the former is used for recording/returning them in an ItWent object. I'm now wondering if/why these two belong in the same family... It sort of makes sense...

Question: did [WFe]Sys\Events\MsgsOp ever do anything besides error-messages? I've been assuming the answer is "no" -- and this seems to be confirmed by the fact that the only thing the podling-classes do is define ErrorsAdminClass() and the only thing the parent caMsgsOp class itself does is HandleResults() (which, as noted earlier, gets its list of potential Messages from the ItWent object that gets passed to it, i.e. the MsgsOp object does not maintain them).

Answer: it appears not; tentatively, this clade-family can be removed.

(Code changes 3 & 4 were here; moved below.)

Question: does it still make sense for individual error-messages (e.g. [WFe]Sys\Data\Engine\aux\msgs\Maria\Errors\cError1044) to descend from the Matcher?

Answer: Actually, they don't. The Matcher descends from [WFe]Sys\Events\Message, but individual errors descend from [WFe]Sys\Events\Message\Error (singular!).

Question: does it still (or did it ever) make sense for the Matcher to descend from [WFe]Sys\Events\Message?

Answer: Tentatively, I think not.

Code changes:

3. [DONE] Remove [WFe]Sys\Events\MsgsOp & podlings (which includes [WFe]Sys\Data\Engine\aux\msgs\*\Ops).

4. [DONE] Rename [WFe]Sys\Events\Message\Errors to something like [WFe]Sys\Events\Message\Matcher [WFe]Sys\Events\msgs\Matcher.

• Implied: ...and re-parent it to StandardBase.

5. [DONE] Move all the messaging stuff from [WFe]Sys\Events to [WFe]Sys\Events\msgs.

• That seems to be just Matcher and Message; MsgsOp will be going away.
• Not sure if iInputItem really belongs here, but it does seem to be in use. Leave it for now.

6. [DONE] Rename [WFe]Sys\Events\Message to [WFe]Sys\Events\Match.

7. TODO: Figure out where/how to do the message-checking (using Matcher).

Question: Shouldn't I be using the Parser subsystem for Matcher? I think I only wrote something from scratch because the Parser seemed too complicated to re-figure out...

• ...or at least maybe Matcher should go in there instead of in Events.

Answer: Matcher does, in fact, use …Parsing\v2\Gene and …Parsing\v2\Nucleus.