You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In working on #191 it became clear that optional fields (i.e those that are pointers) are annoying to work with.
OVSDB Schema's also declare a number of fields immutable and as such it would be best to prevent users from being able to mutate them and expect a result.
Both of these problems could be fixed by using getter/setters. The pattern (which is still idiomaitc Go, even though it feels very object oriented) for this would be as follows:
There are a few issues with this. Firstly, we can't marshal these structs to JSON, as it only supports exported fields.
Secondly, we can only set exported fields using reflection, which is used in the mapper layer 🤔
To combat the first issue, I propose that we follow the pattern that encoding/json uses and effectively consider our ovsdb package to be encoding/ovsdb. We would offer two functions, ovsdb.Marshal and ovsdb.Unmarshal. These operate using ovsdb: struct tags to populate a struct from [[bytes or to serialize a struct in to []bytes.
Alternatively, structs passed in to these functions must honour the interface:
I'm hopeful perhaps that some of what mapper does could make it's way in to ovsdb package.
As for the second issue, we'd need to search for the setter function of a given field and invoke it with an argument, which certainly isn't a straightforward swap.
These would be massive changes to the architecture of libovsdb and would require a lot of discussion....
The text was updated successfully, but these errors were encountered:
In working on #191 it became clear that optional fields (i.e those that are pointers) are annoying to work with.
OVSDB Schema's also declare a number of fields immutable and as such it would be best to prevent users from being able to mutate them and expect a result.
Both of these problems could be fixed by using getter/setters. The pattern (which is still idiomaitc Go, even though it feels very object oriented) for this would be as follows:
There are a few issues with this. Firstly, we can't marshal these structs to JSON, as it only supports exported fields.
Secondly, we can only set exported fields using reflection, which is used in the
mapper
layer 🤔To combat the first issue, I propose that we follow the pattern that
encoding/json
uses and effectively consider ourovsdb
package to beencoding/ovsdb
. We would offer two functions,ovsdb.Marshal
andovsdb.Unmarshal
. These operate usingovsdb:
struct tags to populate a struct from[[bytes
or to serialize a struct in to[]bytes
.Alternatively, structs passed in to these functions must honour the interface:
I'm hopeful perhaps that some of what
mapper
does could make it's way in toovsdb
package.As for the second issue, we'd need to search for the setter function of a given field and invoke it with an argument, which certainly isn't a straightforward swap.
These would be massive changes to the architecture of libovsdb and would require a lot of discussion....
The text was updated successfully, but these errors were encountered: