2021/11/22/PortBank refactoring

Codeblog 2024/11/14 untangling setup calls - mostly just notes to myself 2023/06/04 config classes 2023/05/01 DataPorts redesign 2022/07/21 FutilityCloud process design 2022/08/14 Windows joke I wrote in the late 1900s (on TootCat) 2022/07/21 render-dispatch rubberduckery 2022/07/20 comments on The Home Computer Generation 2022/07/18 layout-event rubberducking 2022/06/24 event-object as output container: the consequences 2022/06/23 event-object as output container: the revision 2022/05/30 more data-class rubberducking 2022/05/20 rubberducking about data classes 2022/01/15 standard CV data format 2021/12/17 The Great Data-Class Restacking 2021/11/25 PHP documentation gripe 2021/11/24 things you can't do in PHP 2021/11/23 PortBank refactoring part 2 2021/11/22 PortBank refactoring part 1 2021/11/08 data objects refactoring 2021/11/05 notes for event-system burndown 2021/07/31 a code mystery 2021/05/31 new PHP wishlist item: first keyword 2021/05/28 a kluge using abstract methods 2021/03/21 PHP wishlist 2020/12/04 (notes) 2020/10/30 (notes) 2020/10/29 (notes) 2020/10/28 (notes) 2020/10/27 (notes: Dovecot on cloud5) 2020/08/29 MediaWiki SpecialPages 2020/08/25 The Plex API 2020/06/12 Ferreteria: thoughts on the Wikcess/flex-data system 2020/04/23 Ferreteria: quick notes on a design issue 2020/04/22 Ferreteria: some thoughts on apps vs. frameworks 2020/02/10 job application (yes, I actually sent this in)

Thinking

We have a bit of a mess going on with the way PortBank Rows interact with the Record objects they use for I/O. I'm mainly looking at the input side of things right now, but any solution needs to also take output ops into account as well.

The problem is:

• PortBanks are attached to a Table, because there's a lot of fiddly field-creation that we don't want to have to recreate every time we load a new row, but we also need to make sure that the data in each PortRow doesn't persist when a new Row is loaded. (This created the alarming situation of user #1 being greeted as user #3 when viewing all of the user records -- something that most users wouldn't have permission to do, but which still suggests this could represent a huge security hole.)
• A Record should really be one and the same with the Storage PortRow; some of its operations really belong to the Logic or Display PortRow classes, where they relate to native calculations, display formatting, or user-input processing.

Task A

I think what I want is something like a mode-switch that tells everything within the Bank what the flow of data should be. When we're trying to read a Unit which has not been set, it should know whether or not to try to calculate a value by converting from its counterpart in one of the other PortRows. When we're trying to write out to Storage or Display, the PortRow being used for output should know whether to fill in missing Units by converting from one of the other two PortRows.

I think that should look like this:

• Each PortRow has a DataSource pointer which tells it where to convert from (NULL = self).
• When a new Row is read in to one of the I/O PortRows, the pointers for each PortRow are updated and existing data is cleared.

Example -- Storage reads a new row:

• Storage DataSource is set to NULL
• Native DataSource is set to Storage
• Display DataSource is set to Native

Task B

We also need to merge cStorageRow into the class-family somehow. Existing parentage:

• cStorageRow ← cPortIORow ← caPortRowInternalDirect ← caPortRowInternal ← caPortRow (root)
  • caPortRow provides a few bits of connective tissue between itself and the PortBank, and then a bunch of Unit-access methods which are basically Array-access methods except each cell is a Unit instead of a value.
  • caPortRowInternal defines an internal array and provides access methods for it, but does not implement the caPortRow access API
  • caPortRowInternalDirect connects those access methods with the API
• cSingleRow ← F\cArrayLocalRW ← tArrayLocal ← taArrayReader
  • taArrayReader provides a single abstract method for reading an array, and implements read-only methods using that
  • taArrayWriter (just written) abstracts write methods
  • tArrayLocal defines an internal array and provides R/W access methods for it
  • tArrayHolder (not used here) provides a wrapper for a locally-stored ArrayLocal object, using the same API as ArrayLocal

There should be a way to replace caPortRowInternal with tArrayLocal, I think. For that matter, caPortRow is really just ArrayLocal plus PortBank-connector stuff plus "Unit"-named aliases for the ArrayLocal API.