groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Possible New Groovy Features... - Deduce the type of final fields from their assigned value
Date Fri, 25 Aug 2017 08:09:14 GMT
for me that is a feature likely to go. If you define a dynamic ctor, it 
should return an object of at least the type that the ctor is for. I do 
not care about subclasses or such, but I don't like Date result = new 
Date() to fail.

On 25.08.2017 04:28, Paul King wrote:
> I've only seen it used in the context of testing, e.g. where a Map of
> Closures might be returned instead of the real object. But I don't know
> what other uses people may have used it for in situations like DSLs.
> Cheers, Paul.
> On Fri, Aug 25, 2017 at 11:00 AM, MG <
> <>> wrote:
>     Ehm - but that is something that _should_ fail in my book, since it
>     violates the contract of what a ctor does (namely create an object
>     of his type).
>     I am not saying Groovy should go out of its way to _prevent_ code
>     like this - but if I had to choose between _this_ working and the
>     imho helpful (and to me obvious) feature that final defined objects
>     automatically carry their actual type instead of all being
>     Object|s... well... you get my drift...
>     Or do you see any application of doing something like this in a real
>     word scenario, e.g. in the context of a DSL ?
>     Markus
>     On 24.08.2017 14:07, Paul King wrote:
>>     It might be something that could work with @CompileStatic. For
>>     dynamic Groovy, I am not sure this can be done. Consider the
>>     following example which, although is dubious style, is valid Groovy:
>>     Date.metaClass.constructor = { 42 }
>>     final result = new Date()
>>     assert result instanceof Integer
>>     assert result == 42
>>     Cheers, Paul.
>>     On Wed, Aug 23, 2017 at 8:45 AM, MG <
>>     <>> wrote:
>>         Hi Paul,
>>         On 21.08.2017 04:30, Paul King wrote:
>>>         Deduce the type of final fields from their assigned value:
>>>             class Foo {
>>>             final device = new PrinterDevice(...) // device field
>>>             will have type PrinterDevice instead of Object when
>>>             reflection is used on class Foo
>>>             }
>>>             Rationale: While IntelliJ does a good job at deducing the
>>>             type of final fields, it would still be better if the
>>>             Groovy language itself would use the more specialized
>>>             type here, for e.g. reflection purposes
>>>         With @Typechecked or @CompileStatic type inferencing is going
>>>         to be in play. During debugging the runtime type is going to
>>>         be available. What "reflective purposes" did you have in mind?
>>         In my framework I iterate over the fields of classes, which
>>         are of type Object, if the have been defined in a compact way
>>         using just final, without an explicit type - it would be
>>         helpful to have the type here.
>>         And in general it just feels like a lost opportunity that
>>         final fields/variables do not auto get the type of their
>>         assigned value - having more information available is never bad.
>>         Of course I am talking about this naively from a user's
>>         perspective: Do you think adding this would a) be hard / time
>>         intensive (naively I would have thought no), b) break
>>         backwards comptability (since the final variable/field cannot
>>         be reassigned... (?))...
>>         Cheers,
>>         Markus

View raw message