Looking at dom::Elem.onEvent() I notice the handler is after the useCapture argument breaking consistency with the Javascript counterpart addEventListener().
I assume this is so onEvent() can make use of it-block handler functions.
If so, is this not a limitation of Fantom?
As in, I see no reason why it-blocks can't be considered as the last argument to a method, as oppose to (as it is now) the last parameter of a method.
There are multiple situations in many of my APIs where having default arguments (for lesser used options) after a common function argument would be really useful to me.
andyThu 25 Jan 2018
Were you missing / implying a piece of proposal?
That you could leave off trailing default arguments and still use the it-block?
I've run into stuff like that a few times -- but not sure I feel strongly enough to change the language -- be interested in others' thoughts?
SlimerDudeThu 25 Jan 2018
That you could leave off trailing default arguments and still use the it-block?
Exactly.
onEvent() is a good example, for 99% of the time my code doesn't have to worry about useCapture - but now I'm forced to consider it every time, purely for the convenience of being able to use an it-block.
I've run into (...) that a few times
Oh good! I notice that dom / domkit uses functions and it-blocks a lot for various handlers - it's a nice design.
change the language
I see it as an enhancement, an evolution even! And I'm pretty sure it's backwards compatible too.
brianSun 28 Jan 2018
Seems like if that flag is hardly ever used, that maybe we should simply the common case for onEvent and have another method like onEventCapture or something.
I do think the convention should always be to make it-blocks the last argument.
SlimerDude Thu 25 Jan 2018
Looking at dom::Elem.onEvent() I notice the handler is after the
useCapture
argument breaking consistency with the Javascript counterpart addEventListener().I assume this is so
onEvent()
can make use of it-block handler functions.If so, is this not a limitation of Fantom?
As in, I see no reason why it-blocks can't be considered as the last argument to a method, as oppose to (as it is now) the last parameter of a method.
Then
onEvent()
could have been / be defined as:may be either called shorthand with an it-block:
Or long hand to incorporate lesser used args:
There are multiple situations in many of my APIs where having default arguments (for lesser used options) after a common function argument would be really useful to me.
andy Thu 25 Jan 2018
Were you missing / implying a piece of proposal?
That you could leave off trailing default arguments and still use the it-block?
I've run into stuff like that a few times -- but not sure I feel strongly enough to change the language -- be interested in others' thoughts?
SlimerDude Thu 25 Jan 2018
Exactly.
onEvent()
is a good example, for 99% of the time my code doesn't have to worry aboutuseCapture
- but now I'm forced to consider it every time, purely for the convenience of being able to use an it-block.Oh good! I notice that dom / domkit uses functions and it-blocks a lot for various handlers - it's a nice design.
I see it as an enhancement, an evolution even! And I'm pretty sure it's backwards compatible too.
brian Sun 28 Jan 2018
Seems like if that flag is hardly ever used, that maybe we should simply the common case for onEvent and have another method like onEventCapture or something.
I do think the convention should always be to make it-blocks the last argument.