Roshan Dawrani | 1 Dec 04:41 2010
Picon

Re: [groovy-dev] DeclarationExpression.getVariableExpression should be deprecated?

On Wed, Dec 1, 2010 at 2:44 AM, Hamlet D'Arcy <hamletdrc <at> gmail.com> wrote:
can you rebuild, resync, and retry again?

thanks,


I have built the latest trunk sources and the same issue is still there..

Is opening the AST of "def x = 1" really throwing any exception that swallowing of exceptions in the newly introduced worker threads was the reason for the AST browser coming up all empty?

Want me to create a JIRA for it?
Paul King | 1 Dec 05:09 2010
Picon

Re: [groovy-dev] DeclarationExpression.getVariableExpression should be deprecated?

On 1/12/2010 6:20 AM, Hamlet DArcy wrote:
> Let's just deprecate the method and leave it at that.

There seems to be a bunch of warnings now that weren't cleaned up
when the method was deprecated.

Cheers, Paul.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Paul King | 1 Dec 05:17 2010
Picon

Re: [groovy-dev] DeclarationExpression.getVariableExpression should be deprecated?


I am fixing the Category AST warning now - which unsurfaced a bug. ;-)

Paul.

On 1/12/2010 2:09 PM, Paul King wrote:
> On 1/12/2010 6:20 AM, Hamlet DArcy wrote:
>> Let's just deprecate the method and leave it at that.
>
> There seems to be a bunch of warnings now that weren't cleaned up
> when the method was deprecated.
>
> Cheers, Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Roshan Dawrani | 1 Dec 06:47 2010
Picon

Re: [groovy-dev] DeclarationExpression.getVariableExpression should be deprecated?

On Wed, Dec 1, 2010 at 9:11 AM, Roshan Dawrani <roshandawrani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Wed, Dec 1, 2010 at 2:44 AM, Hamlet D'Arcy <hamletdrc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
can you rebuild, resync, and retry again?

thanks,


I have built the latest trunk sources and the same issue is still there..

Oh, the tree / property table are getting populated now. It got populated after a while and while it was empty, there was no UI indication on the UI that some background work was happening.

Since the AST data loading is happening in non-UI threads now, some progress message will help. Else the UI looks confusing.

Roshan Dawrani | 1 Dec 07:11 2010
Picon

Re: [groovy-dev] DeclarationExpression.getVariableExpression should be deprecated?

On Wed, Dec 1, 2010 at 11:17 AM, Roshan Dawrani <roshandawrani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Since the AST data loading is happening in non-UI threads now, some progress message will help. Else the UI looks confusing.


Created http://jira.codehaus.org/browse/GROOVY-4547 for the some issues that I noticed in the new AST Browser UI.
Hamlet DArcy | 1 Dec 07:31 2010

Re: [groovy-dev] DeclarationExpression.getVariableExpression should be deprecated?

>> am fixing the Category AST warning now - which unsurfaced a bug. ;-) 

Yes, we need to analyze each usage and see if that usage breaks when a multiple assignment is encountered.
Should we create a JIRA placeholder for this and I can do the analysis over the next couple days? 

>> Created http://jira.codehaus.org/browse/GROOVY-4547 for the some issues that I noticed in the new
AST Browser UI. 

Thanks Roshan. It is assigned to you but feel free to assign it to me. 

-- 
Hamlet D'Arcy 
hamlet.darcy@... 

----- Original Message ----- 

I am fixing the Category AST warning now - which unsurfaced a bug. ;-) 

Paul. 

On 1/12/2010 2:09 PM, Paul King wrote: 
> On 1/12/2010 6:20 AM, Hamlet DArcy wrote: 
>> Let's just deprecate the method and leave it at that. 
> 
> There seems to be a bunch of warnings now that weren't cleaned up 
> when the method was deprecated. 
> 
> Cheers, Paul. 
> 
> --------------------------------------------------------------------- 
> To unsubscribe from this list, please visit: 
> 
> http://xircles.codehaus.org/manage_email 
> 
> 
> 

--------------------------------------------------------------------- 
To unsubscribe from this list, please visit: 

http://xircles.codehaus.org/manage_email 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Hamlet DArcy | 1 Dec 12:46 2010

Re: [groovy-dev] DeclarationExpression.getVariableExpression should be deprecated?

Back to the discussion of DeclarationExpression... 

This object has the following API: 

class DeclarationExpression 
  - DeclarationExpression(Expression, Token, Expression) - For this constructor the left expression
_must_ be of type VariableExpression or a TupleExpression with one or more elements. 
  - getVariableExpression() : VariableExpression - as we discussed, this can throw a ClassCastException
  - isMultipleAssignmentDeclaration() - returns true if the left hand side is a ArgumentListExpression

So... 

I added deprecated to getVariableExpression() and we found two bugs in Groovy. Both have JIRAs. However,
the isMultipleAssignmentDeclaration() method does exist, and there is a safe way to work with this
object. 

I think we should remove the deprecation and write better javadoc for the object. Since the API allows safe
usage there is no need for a deprecation. I did this already but have not checked in. What do you think? 

Second issue: It is possible to create a DeclarationExpression with a TupleExpression that is _not_ an
ArgumentListExpression. In this case isMultipleAssignmentDeclaration() returns false but
getVariableExpression() still throws an exception. I believe we should change the implementation of
this method from: 
    public boolean isMultipleAssignmentDeclaration() {
        return getLeftExpression() instanceof ArgumentListExpression;
    }
to: 
    public boolean isMultipleAssignmentDeclaration() {
        return getLeftExpression() instanceof TupleExpression;
    }

Is that correct? 

Thanks, 

--
Hamlet D'Arcy
hamlet.darcy@...

----- Original Message -----
> >> am fixing the Category AST warning now - which unsurfaced a bug.
> >> ;-)
> 
> Yes, we need to analyze each usage and see if that usage breaks when a
> multiple assignment is encountered. Should we create a JIRA
> placeholder for this and I can do the analysis over the next couple
> days?
> 
> 
> >> Created http://jira.codehaus.org/browse/GROOVY-4547 for the some
> >> issues that I noticed in the new AST Browser UI.
> 
> Thanks Roshan. It is assigned to you but feel free to assign it to me.
> 
> --
> Hamlet D'Arcy
> hamlet.darcy@...
> 
> ----- Original Message -----
> 
> 
> 
> I am fixing the Category AST warning now - which unsurfaced a bug. ;-)
> 
> Paul.
> 
> On 1/12/2010 2:09 PM, Paul King wrote:
> > On 1/12/2010 6:20 AM, Hamlet DArcy wrote:
> >> Let's just deprecate the method and leave it at that.
> >
> > There seems to be a bunch of warnings now that weren't cleaned up
> > when the method was deprecated.
> >
> > Cheers, Paul.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
> http://xircles.codehaus.org/manage_email
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
> http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Jochen Theodorou | 1 Dec 17:07 2010
Picon

Re: [groovy-dev] DeclarationExpression.getVariableExpression should be deprecated?

Hamlet DArcy wrote:
> Back to the discussion of DeclarationExpression... 
> 
> This object has the following API: 
> 
> class DeclarationExpression 
>   - DeclarationExpression(Expression, Token, Expression) - For this constructor the left expression
_must_ be of type VariableExpression or a TupleExpression with one or more elements. 
>   - getVariableExpression() : VariableExpression - as we discussed, this can throw a ClassCastException
>   - isMultipleAssignmentDeclaration() - returns true if the left hand side is a ArgumentListExpression

looking at your changes the last one should be TupleExpression ;)

> So...
> 
> I added deprecated to getVariableExpression() and we found two bugs
> in Groovy. Both have JIRAs. However, the isMultipleAssignmentDeclaration()
> method does exist, and there is a safe way to work with this object.
> 
> I think we should remove the deprecation and write better javadoc for
> the object. Since the API allows safe usage there is no need for a
> deprecation. I did this already but have not checked in. What do you think?

ok I think.

> Second issue: It is possible to create a DeclarationExpression with a TupleExpression that is _not_ an
ArgumentListExpression. In this case isMultipleAssignmentDeclaration() returns false but
getVariableExpression() still throws an exception. I believe we should change the implementation of
this method from: 
>     public boolean isMultipleAssignmentDeclaration() {
>         return getLeftExpression() instanceof ArgumentListExpression;
>     }
> to: 
>     public boolean isMultipleAssignmentDeclaration() {
>         return getLeftExpression() instanceof TupleExpression;
>     }
> 
> Is that correct? 

I think that change is good as well.

One more question though... can the Ast UI now make something usefull 
out of null or not? For example what if the rightExpression is null? 
what if the rightExpression is an EmptyExpression?

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Hamlet DArcy | 1 Dec 17:54 2010

Re: [groovy-dev] DeclarationExpression.getVariableExpression should be deprecated?

> One more question though... can the Ast UI now make something usefull
> out of null or not? For example what if the rightExpression is null?
> what if the rightExpression is an EmptyExpression?

Yes, I handles nulls just fine, as well as EmptyExpressions. 

--
Hamlet D'Arcy
hamlet.darcy@...

----- Original Message -----
> Hamlet DArcy wrote:
> > Back to the discussion of DeclarationExpression...
> >
> > This object has the following API:
> >
> > class DeclarationExpression
> >   - DeclarationExpression(Expression, Token, Expression) - For this
> >   constructor the left expression _must_ be of type
> >   VariableExpression or a TupleExpression with one or more elements.
> >   - getVariableExpression() : VariableExpression - as we discussed,
> >   this can throw a ClassCastException
> >   - isMultipleAssignmentDeclaration() - returns true if the left
> >   hand side is a ArgumentListExpression
> 
> looking at your changes the last one should be TupleExpression ;)
> 
> > So...
> >
> > I added deprecated to getVariableExpression() and we found two bugs
> > in Groovy. Both have JIRAs. However, the
> > isMultipleAssignmentDeclaration()
> > method does exist, and there is a safe way to work with this object.
> >
> > I think we should remove the deprecation and write better javadoc
> > for
> > the object. Since the API allows safe usage there is no need for a
> > deprecation. I did this already but have not checked in. What do you
> > think?
> 
> ok I think.
> 
> > Second issue: It is possible to create a DeclarationExpression with
> > a TupleExpression that is _not_ an ArgumentListExpression. In this
> > case isMultipleAssignmentDeclaration() returns false but
> > getVariableExpression() still throws an exception. I believe we
> > should change the implementation of this method from:
> >     public boolean isMultipleAssignmentDeclaration() {
> >         return getLeftExpression() instanceof
> >         ArgumentListExpression;
> >     }
> > to:
> >     public boolean isMultipleAssignmentDeclaration() {
> >         return getLeftExpression() instanceof TupleExpression;
> >     }
> >
> > Is that correct?
> 
> I think that change is good as well.
> 
> One more question though... can the Ast UI now make something usefull
> out of null or not? For example what if the rightExpression is null?
> what if the rightExpression is an EmptyExpression?
> 
> bye blackdrag
> 
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead
> http://blackdragsview.blogspot.com/
> For Groovy programming sources visit http://groovy.codehaus.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
> http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Matthew Adams | 1 Dec 21:24 2010

[groovy-dev] AST questions

Hi,

Writing my first AST transformation, and had a question.

Consider the following, all in package "org.example":
=====
public enum Color { RED, GREEN, BLUE }
=====
<at> Target(ElementType.FIELD)
public <at> interface Bar { Color color() default RED; }
=====

Example usage of <at> Bar:
class Thing {
  <at> Bar(color=Color.BLUE) String watchamacallit
}

If I'm in my "void visit(ASTNode[] nodes, SourceUnit unit)" method, how to I get the value of the "color" member of the AnnotationNode, assuming I already have the annotation node as a variable called "anno"?  How do I compare that value to see if it's Color.RED, Color.GREEN or Color.BLUE?

For example:

AnnotationNode anno = ... // assume I get it here
switch (anno.???) {
  case Color.RED: // do I use literally Color.RED or some expression for Color.RED?
    // do stuff
    break
  case Color.GREEN: // same question here
    // do stuff
    break
  case Color.BLUE: // same question here
    // do stuff
    break
}

Thanks,
Matthew

--
mailto:matthew-i0dBfVS/lx4ODPX2qTFnTw@public.gmane.org
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
msn:matthew-i0dBfVS/lx4ODPX2qTFnTw@public.gmane.org
http://matthewadams.me
http://www.linkedin.com/in/matthewadams


Gmane