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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
