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 earlier discussions, such as #15, we talked about about working with an "HDF5 DataType that describes a pointer to x". As it is right now, whenever we are receiving a pointer, we are dereferencing it and are working with the underlying value.
The code that was at the center of the discussion was:
when creating a DataType
case reflect.Ptr:
returnNewDataTypeFromType(t.Elem())
and when performing encoding in our cmem package:
case reflect.Ptr:
returnenc.Encode(rv.Elem())
Looking at the HDF5 Documentation describing that topic, one notices that this is a bit more complex than we thought in our discussions. The guys there have a separate interface for handling the issue: Reference Interface.
Therefore, if we want to support those referencing types, we would need to create a wrapper for the named interface.
What still would not be resolved by adding the interface, is the issue of what happens if someone would try to e.g. append a pointer to a Go value without going through such an interface. Would we error? Or would we keep the status quo?
The text was updated successfully, but these errors were encountered:
In earlier discussions, such as #15, we talked about about working with an "HDF5 DataType that describes a pointer to x". As it is right now, whenever we are receiving a pointer, we are dereferencing it and are working with the underlying value.
The code that was at the center of the discussion was:
when creating a
DataType
and when performing encoding in our
cmem
package:Looking at the HDF5 Documentation describing that topic, one notices that this is a bit more complex than we thought in our discussions. The guys there have a separate interface for handling the issue: Reference Interface.
Therefore, if we want to support those referencing types, we would need to create a wrapper for the named interface.
What still would not be resolved by adding the interface, is the issue of what happens if someone would try to e.g. append a pointer to a Go value without going through such an interface. Would we error? Or would we keep the status quo?
The text was updated successfully, but these errors were encountered: