On 05.10.2016 08:13, Graeme Rocher wrote:
[...]
So again let's revisit the benefits of this change:
1) You can write classes annotated with @CompileStatic and use
builders without having to compromise the design of your code
2) You can get type checking for non-builder methods if concrete types
are used in methodMissing (example "methodMissing(String, Closure)"
and type checking for properties if "propertyMissing" is not defined
3) You will get better performance and no matter what we do to the
dynamic side that will stay the same
4) Our goal should be that as much code as possible is compileable
with @CompileStatic and this change helps that
I would appreciate to exclude (1) from the discussion for now. Third
party bias and fears will not lead to a constructive discussion.
Then for (2)... methodMissing(String, Closure) will not get you anywhere
in terms of type checking. This is for methods "foo{...}" or "bar{...}",
where bar and foo are the String. If you write foobar instead, there is
nothing preventing compilation and failure at runtime. And it does not
scale: The more methodMissing you have, the less likely there is the
chance for a compilation error due to builder method argument. And I
actually still fail to see how you want to use this with
@DelegateTo(Map), unless all builder methods of that form will have
these properties.
(3) depends on the implementation. Your suggestion will not give the
best performance, neither in the static, nor in the dynamic world. Which
really makes it difficult for me to see the performance argument. You
are right in that using something like categories will make performance
degrade of course.
And (4)... looks more like a result of (1) to me and will not help
discussion.. Unless you say you only want a builder that will pass
static compilation and don´t care about real type checking and
performance. In that case we can shorten this discussion a lot.
bye Jochen
