Development of the Groovy language ()

Roshan Dawrani | 1 Dec 2010 04:41

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?

headers

Paul King | 1 Dec 2010 05:09

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

headers

Paul King | 1 Dec 2010 05:17

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

headers

Roshan Dawrani | 1 Dec 2010 06:47

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.

headers

Roshan Dawrani | 1 Dec 2010 07:11

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.

headers

Hamlet DArcy | 1 Dec 2010 07:31

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

headers

Hamlet DArcy | 1 Dec 2010 12:46

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

headers

Jochen Theodorou | 1 Dec 2010 17:07

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

headers

Hamlet DArcy | 1 Dec 2010 17:54

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

headers

Matthew Adams | 1 Dec 2010 21:24

[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

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

20	May 2013
35	April 2013
40	March 2013
37	February 2013
54	January 2013
16	December 2012
19	November 2012
50	October 2012
78	September 2012
37	August 2012
90	July 2012
112	June 2012
201	May 2012
67	April 2012
82	March 2012
93	February 2012
31	January 2012
64	December 2011
174	November 2011
63	October 2011
205	September 2011
77	August 2011
98	July 2011
222	June 2011
228	May 2011
150	April 2011
86	March 2011
169	February 2011
157	January 2011
211	December 2010
236	November 2010
194	October 2010
139	September 2010
136	August 2010
175	July 2010
93	June 2010
85	May 2010
82	April 2010
126	March 2010
134	February 2010
101	January 2010
408	December 2009
204	November 2009
311	October 2009
275	September 2009
114	August 2009
114	July 2009
139	June 2009
141	May 2009
232	April 2009
270	March 2009
182	February 2009
310	January 2009
459	December 2008
232	November 2008
499	October 2008
362	September 2008
195	August 2008
339	July 2008
485	June 2008
345	May 2008
607	April 2008
412	March 2008
381	February 2008
490	January 2008
638	December 2007
586	November 2007
528	October 2007
540	September 2007
735	August 2007
536	July 2007
316	June 2007
686	May 2007
499	April 2007
622	March 2007
923	February 2007
521	January 2007
483	December 2006
172	November 2006
126	October 2006
1	August 2006
22	June 2006
67	May 2006
200	April 2006
549	March 2006
266	February 2006
242	January 2006
99	December 2005
360	November 2005
256	October 2005
110	September 2005
116	August 2005
358	July 2005
300	June 2005
149	May 2005
77	April 2005
165	March 2005
149	February 2005
288	January 2005
283	December 2004
30	November 2004
55	October 2004
84	September 2004
75	August 2004
255	July 2004
90	June 2004
199	May 2004
354	April 2004
315	March 2004
215	February 2004
177	January 2004