Need option types #6

New Issue

sashakoshka · 2025-07-20T18:44:34-06:00

sashakoshka commented

2025-07-20 18:44:34 -06:00

No idea why it took me until now to figure this out, but we need them. There are three options:

Use pointers
Use the go-util option type
Provide an alias for the go-util option type
Implement the type here

First option is bone-headed because if you have a table of like 16 optional integers, that's potentially 16+ allocs for what could just be a flat struct. That's not to mention the (albeit minor) performance penalty incurred due to pointer indirection when using the data.

Second option is still not ideal because that hardwires a completely different module into this one's public API, but it isn't without precedent, and go-util is used everywhere in holanet anyway. The intention was for it to be an extension to the standard library, so perhaps it's time to really lean into that.

Third option isn't all that different from the second because an alias is really, really thin. It would mean one less package to import, though, which is good.

Fourth option is so stupid. This would make two competing option types within holanet and I am the only person in holanet so that isn't even remotely productive.

Thinking of the third.

No idea why it took me until now to figure this out, but we need them. There are three options: 1. Use pointers 2. Use the go-util option type 3. Provide an alias for the go-util option type 4. Implement the type here First option is bone-headed because if you have a table of like 16 optional integers, that's potentially 16+ allocs for what could just be a flat struct. That's not to mention the (albeit minor) performance penalty incurred due to pointer indirection when using the data. Second option is still not ideal because that hardwires a completely different module into this one's public API, but it isn't without precedent, and go-util is used everywhere in holanet anyway. The intention was for it to be an extension to the standard library, so perhaps it's time to really lean into that. Third option isn't all that different from the second because an alias is really, really thin. It would mean one less package to import, though, which is good. Fourth option is so stupid. This would make two competing option types within holanet and I am the only person in holanet so that isn't even remotely productive. Thinking of the third.

sashakoshka commented

2025-07-20 18:47:29 -06:00

Need to find out how this would work in PDL as well. Why not copy Zig:

M000 SomeMessage {
        0000 SomeField String
        0001 OtherField ?String
}

Need to find out how this would work in PDL as well. Why not copy Zig: ``` M000 SomeMessage { 0000 SomeField String 0001 OtherField ?String } ```

sashakoshka commented

2025-07-20 19:01:05 -06:00

Hmm, we would need to avoid parsing this as part of the pair type, it must be parsed as part of the table pair itself. This is because it doesn't really mean anything outside of the context of a table, not even within an OTA.

Sign in to join this conversation.

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sashakoshka/hopp#6