groovy

@Field cannot annotate a multiple assignment expression. throws a ClassCastException

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.8-beta-2
  • Fix Version/s: 1.8-beta-3
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

@Field cannot annotate a multiple assignment expression. throws a ClassCastException

This was found become because DeclarationExpression.getVariableExpression() was deprecated.

A failing test case is: 

@groovy.transform.Field 
def (awe, awe2) = [[1, 2, 3], [1, 2, 3]]

def awesum() { awe.sum() }
assert awesum() == 6

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Paul King added a comment -

I have removed the ClassCastException with a compile time error saying that the multiple assignment isn't currently supported. We now need to decide if we want to support that form.

Show
Paul King added a comment - I have removed the ClassCastException with a compile time error saying that the multiple assignment isn't currently supported. We now need to decide if we want to support that form.
Hide
Permalink
Hamlet D'Arcy added a comment -

Thanks Paul. Is there a reason not to support multiple assignments on @Field? Is it hard to implement?

Show
Hamlet D'Arcy added a comment - Thanks Paul. Is there a reason not to support multiple assignments on @Field? Is it hard to implement?
Hide
Permalink
Paul King added a comment - - edited

It is a little tricky but not impossible. There are arguments for and against. I guess the fact that we don't support such syntax for normal class fields worries me a little. I.e. the following is not currently allowed:

class Foo {
  def (bar, baz) = [1, 2]
}

So, in some sense we are providing a backdoor way to write such things for the main script class.

Show
Paul King added a comment - - edited It is a little tricky but not impossible. There are arguments for and against. I guess the fact that we don't support such syntax for normal class fields worries me a little. I.e. the following is not currently allowed: class Foo { def (bar, baz) = [1, 2] } So, in some sense we are providing a backdoor way to write such things for the main script class.
Hide
Permalink
Hamlet D'Arcy added a comment -

seems reasonable to disallow it then.

Show
Hamlet D'Arcy added a comment - seems reasonable to disallow it then.
Hide
Permalink
Paul King added a comment - - edited

Let's close it then for now. Someone can always make a strong case for why we should go further.

Show
Paul King added a comment - - edited Let's close it then for now. Someone can always make a strong case for why we should go further.

People

  • Assignee:
    Paul King
    Reporter:
    Hamlet D'Arcy
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: