-
Notifications
You must be signed in to change notification settings - Fork 7
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
Add "function" type to can-define #392
Comments
I don't know what the existing behavior for a type mismatch is, but I would expect it to throw. |
@thomaswilburn the existing behavior is coercion. For example,
We don't throw. For that, there is this proposal: #334 |
How would you define the default value for this? DefineMap.extend({
update: {
type: "function",
default() {
return function() { ... }
}
}
}); vs. how you would do it now: DefineMap.extend({
update() {
// ...
}
}); |
@matthewp we could special case a |
I think the value should still be coerced (I assume something like
I think a special syntax ( DefineMap.extend({
update: {
type: "function",
default() {
return function() {};
}
}
});
I /do not/ think methods should be able to be redefined. If you want to change out functions on a DefineMap, make it a property and not a method. |
Passing functions is much more common with CanJS. I'd like to add a "function" type so these properties can be clearly identified.
Instead of:
We'd be able to write:
Or:
Questions
What should happen if people pass something other than
null
,undefined
, or afunction
?null
?How should we handle default values?
Should a default look like this to be consistent?
What should we do with methods that are set?
We probably should not make
update()
a settable property because that would mean we have to make.update()
always go through a getter and callObservation.add()
. It's probably not worth the performance cost.The text was updated successfully, but these errors were encountered: