2022/05/20/rubberducking about data classes

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)

A transcript of me rubberducking Ferreteria data class design 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