Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Register encode/decode funcs instead of types #699

Closed
wants to merge 7 commits into from
Closed

Conversation

deosjr
Copy link

@deosjr deosjr commented Dec 6, 2023

This change would allow users to register a function to encode or decode extensionobjects they read with a custom function, bypassing the default behaviour that comes from registering a type.
This would enable for example to decode an extensionobject into a type generated at runtime.

@@ -38,9 +65,9 @@ type ExtensionObject struct {
Value interface{}
}

func NewExtensionObject(value interface{}) *ExtensionObject {
func NewExtensionObject(value interface{}, typeID *ExpandedNodeID) *ExtensionObject {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It worth making a comment why and what typeID need to be provided i think

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No one should be using this function imo

ua/decode.go Show resolved Hide resolved
df := func(b []byte, vv interface{}) error {
rv := reflect.ValueOf(vv)
if rv.Kind() != reflect.Pointer || rv.IsNil() {
return fmt.Errorf("incorrect type to decode into")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to return what type is expected to avoid people going to the source code to figure that out.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

err := decode(body.Bytes(), &e.Value)
so currently always true; I took this from example in encoding/json golib.
Perhaps simply removing the check altogether is better


// RegisterExtensionObjectFunc registers a new extension object type using encode and decode functions
// It panics if the type or the id is already registered.
func RegisterExtensionObjectFunc(typeID *NodeID, ef encodefunc, df decodefunc) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this method is public the encodefunc and decodefunc should also be public imo

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? Its essentially an interface that you can still adhere to from outside of the package (see read_unknow_node_id_test.go for example). I don't think anyone should even know about the type name, just the function handle

@@ -28,6 +52,9 @@ const (
ExtensionObjectXML = 2
)

type encodefunc func(v interface{}) ([]byte, error)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

encodefunc and decodefunc should also be public imo

e.Value = eotypes.New(typeID)
if e.Value == nil {
decode := eotypes.DecodeFunc(typeID)
if decode == nil {
debug.Printf("ua: unknown extension object %s", typeID)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this message is a bit misleading after refactoring. What we now register is funcs iiuc

mu sync.Mutex
types map[string]reflect.Type
ids map[reflect.Type]string
type FuncRegistry struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it deserves a comment but wrt to functions

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you feel about renaming the file from typereg.go -> funcreg.go ?

@deosjr
Copy link
Author

deosjr commented Jan 2, 2024

Closing after discussion; this should not be part of this library.

@deosjr deosjr closed this Jan 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants