2022/05/20/rubberducking about data classes

A transcript of me rubberducking at Tessa in Discord:

10:11 AM

Ugh, running into a design issue with Data Cards.

10:12 AM

Cards are supposed to represent the data and functionality for a given data record, in any of 3 possible formats (native/calc, display, storage).

10:13 AM

They're not supposed to be tied to the current state of the Feature (which is kind of like a manager class/object for each table's data -- handles iteration through rowsets, and can spawn Cards as needed for doing single-row-related stuff).

10:14 AM

Sometimes a Display or Storage card needs to access Native data -- but access to other formats goes through the Feature, and the Feature might be on a different row, so we can't count on it to return a Native Card for the same row.

10:15 AM

Maybe what needs to happen is that Display and Storage Cards need to be passed a Native Card at construction time.

10:18 AM

If the Display or Storage Card is processing input, though, the Native Card may not yet have been populated -- so we need to be able to convert (I call it "transload" = translate + load) from Local (Display or Storage) to Native... which, again, currently goes through the Feature object... so either we'd also need to pass the Feature object, or else make the transloading functionality available more directly.

goes to look at how that's currently implemented

2:03 PM

It happens in the PortRow classes -- and there's a divergence between the "native" Row types and the display/storage Row types... but, hm, the problem is how to make that functionality accessible to Cards...

2:04 PM

Obvious thought: maybe the Card classes need to have a similar divergence, with the Display/Storage (I/O Row) classes being initialized with a copy of the Native Row... if it exists. I'll try making it mandatory at first and see what I run into.

3:15 PM

Oops, should have done a commit before I started moving things around >.<

3:23 PM

Maybe I should write a daemon which repeatedly scans project folders looking for changes, and commits them to an "edits" branch -- but I'd definitely need a GUI for that to be useful for recovering best-so-far versions after a big set of changes.

3:52 PM

I think each Card needs to know its Row, because that does the translating, and if the Card is an I/O Card, it needs to know the corresponding Native Card.

4:53 PM

Ah wait, but the I/O Card can grab the current Native Row at the time it's initialized, because it's being initialized with the current data in the Bank (which is all the Rows)... so stuff could change later, but it should be in sync at construction-time.

Follow-up

I ended up reversing most of these changes (keeping the class-split in case of future need) because

• the only field which needed to be cross-referenced was the ID field, which is premised as an integer and therefore does not need conversion
• the name of the key field was needed, which is found in the Spec, which was already being passed