groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Rocher <graeme.roc...@gmail.com>
Subject Re: Proposal: Statically compileable builders
Date Wed, 05 Oct 2016 19:41:05 GMT
On Wed, Oct 5, 2016 at 7:33 PM, Jochen Theodorou <blackdrag@gmx.org> wrote:
> 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.


I am not trying to turn this into a static vs. dynamic debate. I love
both, all I'm trying to propose is the improve the experience for
users of @CS. If the community is not interested in that then so be
it.



>
> 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.

I disagree. It is quite a common pattern to have dynamic methods, but
type checked properties. See for example MarkupTemplateEngine which
has special extensions to allow model variables to be type checked,
whilst method dispatch for builder methods remains dynamic:

http://docs.groovy-lang.org/latest/html/documentation/markup-template-engine.html#_type_checked_templates

Right now in order to achieve this you have to write special extensions:

https://github.com/apache/groovy/blob/master/subprojects/groovy-templates/src/main/groovy/groovy/text/markup/MarkupTemplateTypeCheckingExtension.groovy

We did the same thing for StreamingJsonBuilder by writing a special extension:

https://github.com/grails/grails-views/blob/master/core/src/main/groovy/grails/views/compiler/BuilderTypeCheckingExtension.groovy

The goal here is to be able to type check code like:

String title = "Blah"
mkp.html {
       body {
            h1( title.toUpperCas() ) // compilation error here
       }
}


To implement the above you would implement "methodMissing" but not
"propertyMissing" thus you are able to achieve type checking for
properties and local variables when using the builder, so I disagree
with the statement that we "will not get anywhere in terms of type
checking".



>
> (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.

So lets leave performance out of the argument and discuss the
usability benefits. I'm not trying to create another "dynamic vs.
static" debate here. My goal is to enable us as developers to write
builders and DSLs that are usable from @CS code, something that will
benefit everyone.

The issue with the current mechanism of using a type checking
extension is that you can only then use the extension in certain
contexts (templates compiled by MarkupTemplateEngine or JSON views
compiled by Grails' JSON views) but they're not generally usable in
all Groovy code.

The proposal here is to try and find a solution to that so that the
extensions aren't necessary.

Cheers


>
> 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



-- 
Graeme Rocher

Mime
View raw message