-
-
Notifications
You must be signed in to change notification settings - Fork 221
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
Support creating a global ObjectTemplate into a context #64
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great -- mostly minor comments.
mentioned in the diff inline but in the PR description as well, the Set call's attribute just being passed as "0" is a bit blah. perhaps we should consider a different api to set the property attributes so that could be omitted in the normal case? |
That's me just being lazy. I'll change the examples to use the enum/const. For ObjectTemplate's it's more likely that you want to set Ps. I'm not a huge fan of APIs that have prepositions (e.g. "For", "With", "At", "To") if they can be avoided; adding an argument to a method makes more sense unless the method has a distinct verb. The challenge is that Go does not have overloaded methods, but C++ does, so there will be some compromise needed here (from me). |
That's fair, I think attempting to match the c++ makes sense (and I know it's stated goal). It's just too bad that something as succinct as I'm curious about the use case in mind for exposing the properties here and if we can grow the api surface area at a later time. |
The goals do state to match the C++ API, but still as idiomatic Go as possible (our get out of jail free card 😉 ). This would make the property attribute optional and default to Ps. the PropertyAttribute is also used for normal Objects (not template ones); so would have to do the same there too. What do you think @tmc ? |
So thinking about this a bit more... rather than a varadic function with "SetOptions"... what about just doing a varadic function of PropertyAttributes, because they are flags that can be added together? This is better explained via examples: Current APIfunc (o *ObjectTemplate) Set(name string, val interface{}, attributes PropertyAttribute) error
// the caller would do:
obj.Set("foo", "bar", v8go.ReadOnly)
// or for multiple:
obj.Set("foo", "bar, v8go.ReadOnly | v8go.DontEnum) Proposed API (v2)func (o *ObjectTemplate) Set(name string, val interface{}, attributes ...PropertyAttribute) error
// previous examples would still be valid
obj.Set("foo", "bar", v8go.ReadOnly)
obj.Set("foo", "bar, v8go.ReadOnly | v8go.DontEnum)
// but would also allow for this
obj.Set("foo", "bar")
obj.Set("foo", "bar, v8go.ReadOnly, v8go.DontEnum) In the last example the slice of attributes would be converted to var attrs PropertyAttribute
for _, a := range attributes {
attrs |= a
}
// ie:
obj.Set("foo", "bar, v8go.ReadOnly, v8go.DontEnum)
// is equal to
obj.Set("foo", "bar, v8go.ReadOnly | v8go.DontEnum) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Provides creating a global object that can be initiated within each Context eg:
The same
ObjectTemplate
can be used in many Contexts as long as they are part of the same Isolate (VM).This PR also adds the ability to create primitive values that can be properties on the global object.
This is the prerequisite to
FunctionTemplate
s for the global context.As a side-effect of this PR. The
NewContext()
API has changed to optionally accept a Isolate and a Global Template, this makes for a nice API as you see above, but also allows for this:This is fully backwards compatible.
I've not updated the README.md to not confuse readers, until this is released into a new version.