- No need for a syntax difference between simple closures and markup closures.
- No need for another breaking change that our users would have to bear.
Why a breaking change for markup?
James' proposal introduces a breaking syntactical change to differentiate markup and non-markup closures. Because supposedly static typing could not be preserved without that. But I think this is a misleading statement, and here's why...
Groovy roots with a pinch of humour
Groovy is a dynamic scripting language which can also support static typing. In the expression "dynamic scripting language", there's "dynamic". However, some have been favouring static typing over dynamic and duck typing. And they want to relegate dynamic features aside, in quarantine, as if it were the new plague of the language. Although I firmly believe everyone can live in peace together without anyone left on the side of the road.
I think James' proposal tries to address a problem which doesn't really exist – or at least that can be solved thanks to other mechanisms we've already decided to implement in the JSR. Moreover, it'd introduce a breaking change in people's code by requiring to use a special syntax to support markup closures.
Main concerns about static typing
- we'd like to be able to do code-completion in IDEs,
- we'd want IDEs to support refactoring of Groovy code source too,
- we would also like our users to be aware of the presence of potentially different rules in markup closures,
First of all, at the meeting, we've all agreed we needed a more powerful Meta-Object Protocol which would give us more control on what's called and from where, thanks to more context.
Furthermore, we've also decided that an introspection API is needed. As long as we're using static typing, this introspection API, which will be available from the MetaClass, can tell IDEs and the compiler what names are possible for a given object. And of course, local names can easily be completed without that.
That is, at compile-time or at the time the user writes his code, the methods, properties and fields are known, hence, code-completion (1) and refactoring (2) can be provided by your IDE. Even for builders with static names or with an infinite number of names with a subset of known names.
And eventually, since the user is smart, he knows when using a builder the rules might be a little different. Which makes (3) a non-existing problem. A programmer will never use a method at random, as if he'd not know what a given method was supposed to do.
Problems with the new syntax construct
- it will break people's code, because they will have to support the new syntax for markup,
- even with the syntax difference, automatic refactoring can't always be achieved without the risk of breaking code, that's why IDEs often require some feedback from the user to decide what's exactly to be done,
- it makes me think he believes our users are not smart enough to know that they are using a builder in their code.
Furthermore, if we really want the compiler to not check for names at all for some reason, I think we should use the "dynamic" or "@Dynamic" annotation/keyword at the class or at the method level – that we've discussed at the meeting – to warn the compiler that we really don't want it to check any name. Such a marker/annotation would be definitely more pleasant to read. It'd be an "addition" to the language, and not a breaking change.
All the potential problems James' proposal addresses can be solved easily simply because through the new MOP and through the introspection API we'll design, we'll have everything we need for code-completion, or for refactoring. And it doesn't diserve introducing a new code construct and to break all the usages of builders for problems which are no real problems.
So, in conclusion, we should take actions towards focusing on thinking about the MOP and the introspection API. That's how things we'll become clearer to all of us. While designing these parts, we'll know if this syntax change is needed or not. And I suspect it will not even be needed at all as explained above.