You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Saravanan Palanichamy <ch...@gmail.com> on 2022/12/03 11:04:11 UTC
Disabling auto inferencing
Hello developers
I am developing a DSL and ran into this issue. Groovy auto infers that b is
really a derived clazz and allows me to call the derived clazz method. How
do I prevent this behavior from happening? Are there some settings in the
DeclarationExpression or VariableExpression AST models that will allow me
to prevent this and cause a compile error? (I am writing a compiler
customizer and so have access to do this)
void myMethod() {
> BaseClazz b = new DerivedClazz()
> b.callMethodDefinedOnlyInDerivedClazz("")
> }
>
>
Alternately, this seems to work correctly. But I'd rather not do it this
way if possible
void myMethod() {
> BaseClazz b = (BaseClazz) new DerivedClazz()
> b.callMethodDefinedOnlyInDerivedClazz("")
> }
>
> regards
Saravanan
RE: [EXT] Re: Disabling auto inferencing
Posted by "Milles, Eric (TR Technology) via dev" <de...@groovy.apache.org>.
GROOVY-9064 [1] has further discussion on this topic. It is also the cause for GROOVY-10120 [2] for us. The interface type carries proper generics info but the override method on the implementation class has none (for some odd reason).
[1] https://issues.apache.org/jira/browse/GROOVY-9064
[2] https://issues.apache.org/jira/browse/GROOVY-10120
-----Original Message-----
From: Jochen Theodorou <bl...@gmx.org>
Sent: Monday, December 5, 2022 2:18 AM
To: dev@groovy.apache.org
Subject: [EXT] Re: Disabling auto inferencing
External Email: Use caution with links and attachments.
Am 04.12.22 um 16:34 schrieb Saravanan Palanichamy:
> Thanks Jochen and Christopher for helping clarify behaviour. So if I
> wanted to make sure declaration and not flow type is honored, the
> quickest way is to make sure flow type matches declaration by casting
> it? Are there other ways inside the compiler to fix this (some options
> or some indications in the variable declaration statement itself) (I
> looked and didnt find anything, but thought I'd ask)?
the nodes have meta data, which usually also contains static type information such as the flow type. You would have to make changes here.
What exactly you have to look for and change I cannot say without a deep look into the code myself. Eric Miles would be a good address for this though.
bye Jochen
Re: Disabling auto inferencing
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 04.12.22 um 16:34 schrieb Saravanan Palanichamy:
> Thanks Jochen and Christopher for helping clarify behaviour. So if I
> wanted to make sure declaration and not flow type is honored, the
> quickest way is to make sure flow type matches declaration by casting
> it? Are there other ways inside the compiler to fix this (some options
> or some indications in the variable declaration statement itself) (I
> looked and didnt find anything, but thought I'd ask)?
the nodes have meta data, which usually also contains static type
information such as the flow type. You would have to make changes here.
What exactly you have to look for and change I cannot say without a deep
look into the code myself. Eric Miles would be a good address for this
though.
bye Jochen
Re: Disabling auto inferencing
Posted by Saravanan Palanichamy <ch...@gmail.com>.
Thanks Jochen and Christopher for helping clarify behaviour. So if I wanted
to make sure declaration and not flow type is honored, the quickest way is
to make sure flow type matches declaration by casting it? Are there other
ways inside the compiler to fix this (some options or some indications in
the variable declaration statement itself) (I looked and didnt find
anything, but thought I'd ask)?
I am using 3.0.5 and I compile statically into the file system
regards
Saravanan
On Sun, Dec 4, 2022 at 12:25 AM Jochen Theodorou <bl...@gmx.org> wrote:
> On 03.12.22 15:50, Christopher Smith wrote:
> > I believe the feature at play is "flow typing", and it surprises me that
> > it would apply to variables declared with an explicit type. What version
> > of Groovy are you targeting, and is this compiled statically or
> > dynamically?
>
> The declaration type is to be understood as an base type for the
> variable, not the flow type. Which means in
>
> Y foo = bar()
> foo.x()
>
> the flow type of foo is whatever is inferred as result type for the call
> bar(). The assignment to foo is valid if the result type for the call to
> bar() is assignable to Y. The call x() on foo is valid if the method x()
> exists on the flow type.
>
> This is the intended behaviour.
>
> bye Jochen
>
>
Re: Disabling auto inferencing
Posted by Jochen Theodorou <bl...@gmx.org>.
On 03.12.22 15:50, Christopher Smith wrote:
> I believe the feature at play is "flow typing", and it surprises me that
> it would apply to variables declared with an explicit type. What version
> of Groovy are you targeting, and is this compiled statically or
> dynamically?
The declaration type is to be understood as an base type for the
variable, not the flow type. Which means in
Y foo = bar()
foo.x()
the flow type of foo is whatever is inferred as result type for the call
bar(). The assignment to foo is valid if the result type for the call to
bar() is assignable to Y. The call x() on foo is valid if the method x()
exists on the flow type.
This is the intended behaviour.
bye Jochen
Re: Disabling auto inferencing
Posted by Christopher Smith <ch...@gmail.com>.
I believe the feature at play is "flow typing", and it surprises me that it
would apply to variables declared with an explicit type. What version of
Groovy are you targeting, and is this compiled statically or dynamically?
On Sat, Dec 3, 2022, 05:04 Saravanan Palanichamy <ch...@gmail.com> wrote:
> Hello developers
>
> I am developing a DSL and ran into this issue. Groovy auto infers that b
> is really a derived clazz and allows me to call the derived clazz method.
> How do I prevent this behavior from happening? Are there some settings in
> the DeclarationExpression or VariableExpression AST models that will allow
> me to prevent this and cause a compile error? (I am writing a compiler
> customizer and so have access to do this)
>
> void myMethod() {
>> BaseClazz b = new DerivedClazz()
>> b.callMethodDefinedOnlyInDerivedClazz("")
>> }
>>
>>
> Alternately, this seems to work correctly. But I'd rather not do it this
> way if possible
>
> void myMethod() {
>> BaseClazz b = (BaseClazz) new DerivedClazz()
>> b.callMethodDefinedOnlyInDerivedClazz("")
>> }
>>
>> regards
> Saravanan
>