Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Proposal: tightening up $internalize and $externalize (for zero values) #617

Open
@myitcv

Description

@myitcv

Edit: the discussion has morphed into a proposal; details in this comment (which will continue to be updated)

This is really picking up conversation from #236, to register an issue for a specific problem, namely (playground):

package main

import (
	"fmt"

	"github.com/gopherjs/gopherjs/js"
)

type S struct {
	*js.Object

	A string `js:"A"`
}

func main() {
	o := js.Global.Get("Object").New()
	s := S{Object: o}

	var str string

	str = s.A

	exp := ""

	fmt.Printf("%q == %q: %v", str, exp, str == exp)
	js.Global.Get("console").Call("log", "\"%s\" == \"%s\": %s", str, exp, str == exp)
}

The output of this is:

"undefined" == "": false

in both the browser console and the onscreen-Playground output.

To my mind this is a bug because the compiler generated code is failing to properly internalise an external value which we have defined to be of type string. That internalisation should handle the Javascript undefined value when we "read" the field value and convert it to the GopherJS "" value. The output should be:

"" == "": true

Similarly (and I note the discussion in #504) if the type of A were instead *string then undefined would be converted to nil.

And in any situation where the conversion is not well defined (i.e. if the underlying field had a number value) then we panic.

Furthermore the same conversion concept should apply for fields of all types on *js.Object-special types.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions