Nabble - groovy - user

Re: closure issue in GroovyTestCase

2008-10-07T05:12:56Z

I use 1.5.6 and your simple test works for me as well. But the issue is
that the compiled MyTest_testMe_closure1 does not have public
constructor TestCase(String name) or TestCase()

Thanks

Roshan Dawrani wrote:

> You may want to mention the version of groovy with which you are
> encountering this issue of not being able to use closures in your
> testcase.
>
> With 1.5.6, I am not seeing any issue in executing a test using
> closures as following:
>
> public class MyTest extends GroovyTestCase{
> void setUp() {
> def list = [1, 2, 3, 5]
> def list1 = list.findAll {it > 2}
> println list1
> }
>
> void testMe(){
> def list = [1, 2, 3, 5]
> def list1 = list.findAll {it <= 2}
> println list1
> }
> }
>
> On Tue, Oct 7, 2008 at 4:35 PM, Haotian Sun <hsun@...
> <mailto:hsun@...>> wrote:
>
> Hi Jochen,
>
> Well, I'm not sure what you mean by where I collect the tests. But
> once I have a closure involved in any part of my test, for example,
>
> public class MyTest extends GroovyTestCase{
>
> void setUp() {
> qcIwd =
> iwdXml.executionRecord.ixicoWorkflowDefinitions.IxicoWorkflowDefinition.find
> {it.@iwdtype ==
> 'GENERIC/RESOURCES/ManualExamQC.xml?revision=157'}
> }
> }
>
> I will have a problem as stated before. I see that the JVM will
> compile the closure as a separate class but that one seems not to
> extend the junits' TestCase
>
> Can you please explain a bit more?
>
> Thanks
>
> Haotian
>
> Jochen Theodorou wrote:
>
> Haotian Sun schrieb:
>
> Hi guys,
>
> I've got a junit test class which extends GroovyTestCase,
> when the class involves some Groovy class/script which
> generate closures classes, the test will fail along with
> the message like following:
>
> junit.framework.AssertionFailedError: Class
> MyTest_closure1 has no public constructor TestCase(String
> name) or TestCase()
>
> Does anyone have idea to fix this?
>
>
> you tried to execute the closure classas junit test. You
> should not do that. Look at where you collect the tests and
> how you do that and fix that part ;)
>
> bye blackdrag
>
>
>
> ---------------------------------------------------------------------
> 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

testing assertions not working with shouldFail

2008-10-07T05:00:04Z

hi sometimes i want to unit-test whether an assertion is correctly filed. but somehow this does not work, groovy runtime instantly exits instead of waiting for my shouldFail assertion.

class SUT{
def static sut(param){
assert sut == 3
}
}

public void testSut(){
shouldFail(AssertionError.class,{SUT.sut(2)})
}

instead of passing i get stack trace of java.lang.Assertion, though it should have been caught by my test method? what am i doing wrong?

thanks.

manuel aldana
aldana((at))gmx.de
software-engineering blog: http://www.aldana-online.de

Re: closure issue in GroovyTestCase

2008-10-07T04:26:53Z

You may want to mention the version of groovy with which you are encountering this issue of not being able to use closures in your testcase.

With 1.5.6, I am not seeing any issue in executing a test using closures as following:

public class MyTest extends GroovyTestCase{
    void setUp() {
        def list = [1, 2, 3, 5]
        def list1 = list.findAll {it > 2}
        println list1
    }

    void testMe(){
        def list = [1, 2, 3, 5]
        def list1 = list.findAll {it <= 2}
        println list1
    }
}

On Tue, Oct 7, 2008 at 4:35 PM, Haotian Sun <hsun@...> wrote:

Hi Jochen,

Well, I'm not sure what you mean by where I collect the tests. But once I have a closure involved in any part of my test, for example,

public class MyTest extends GroovyTestCase{

void setUp() {
qcIwd = iwdXml.executionRecord.ixicoWorkflowDefinitions.IxicoWorkflowDefinition.find
{it.@iwdtype == 'GENERIC/RESOURCES/ManualExamQC.xml?revision=157'}
}
}

I will have a problem as stated before. I see that the JVM will compile the closure as a separate class but that one seems not to extend the junits' TestCase

Can you please explain a bit more?

Thanks

Haotian

Jochen Theodorou wrote:

Haotian Sun schrieb:

Hi guys,

I've got a junit test class which extends GroovyTestCase, when the class involves some Groovy class/script which generate closures classes, the test will fail along with the message like following:

junit.framework.AssertionFailedError: Class MyTest_closure1 has no public constructor TestCase(String name) or TestCase()

Does anyone have idea to fix this?

you tried to execute the closure classas junit test. You should not do that. Look at where you collect the tests and how you do that and fix that part ;)

bye blackdrag

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

http://xircles.codehaus.org/manage_email

Re: closure issue in GroovyTestCase

2008-10-07T04:05:37Z

Hi Jochen,

Well, I'm not sure what you mean by where I collect the tests. But once
I have a closure involved in any part of my test, for example,

public class MyTest extends GroovyTestCase{

void setUp() {
qcIwd =
iwdXml.executionRecord.ixicoWorkflowDefinitions.IxicoWorkflowDefinition.find
{it.@iwdtype ==
'GENERIC/RESOURCES/ManualExamQC.xml?revision=157'}
}
}

I will have a problem as stated before. I see that the JVM will compile
the closure as a separate class but that one seems not to extend the
junits' TestCase

Can you please explain a bit more?

Thanks

Haotian

Jochen Theodorou wrote:

> Haotian Sun schrieb:
>> Hi guys,
>>
>> I've got a junit test class which extends GroovyTestCase, when the
>> class involves some Groovy class/script which generate closures
>> classes, the test will fail along with the message like following:
>>
>> junit.framework.AssertionFailedError: Class MyTest_closure1 has no
>> public constructor TestCase(String name) or TestCase()
>>
>> Does anyone have idea to fix this?
>
> you tried to execute the closure classas junit test. You should not do
> that. Look at where you collect the tests and how you do that and fix
> that part ;)
>
> bye blackdrag
>

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

http://xircles.codehaus.org/manage_email

Re: Date.format convenience methods

2008-10-06T07:36:37Z

Great job, Tom, thanks a lot!

On Mon, Oct 6, 2008 at 4:19 PM, Tom Nichols <tmnichols@...> wrote:

> Added a static Date.parse( pattern, input ) method in r.13699. Please
> yell if I break anything -- A lot of unit tests seem to be failing for
> me, even on a clean checkout -- Windows :(
>
> Also, I'd like to get a tally of who thinks the name (or format)
> should be changed for the "quickie" Date format methods. I'll
> reiterate what stands right now:
>
> date.dateString // uses DateFormat.getDateInstance( SHORT ) -
> dd/MM/yy in en_UK
> date.timeString // uses DateFormat.getTimeInstance( MEDIUM ) - HH:mm:ss
> date.dateTimeString // uses DateFormat.getDateTimeInstance( SHORT, MEDIUM )
>
> I think the other proposal was to use "format..." for all of the
> method names like so:
> date.formatDate()
> date.formatTime()
> date.formatDateTime()
>
> Again, my main reason for choosing properties was to aid readability
> in GStrings like
> "Today's date is ${date.dateString}"
> versus
> "Today's date is ${date.formatDate()}"
>
> but if the majority likes the "format.." convention better I can
> switch it. If there isn't more significant discussion on this (or
> argument on why there should be additional DGM methods) I'll consider
> this done and close the JIRA issue.
>
>
> Thanks!!
> -Tom
>
>
> On Thu, Oct 2, 2008 at 3:31 PM, Tom Nichols <tmnichols@...> wrote:
>> Cool! Created issue here: http://jira.codehaus.org/browse/GROOVY-3066
>>
>> Two questions -
>> 1. Should there be a complimentary "parse" method? Something like
>> new Date( 'yyyy-MM-dd', someString )
>>
>> 2. In lieu of creating a new SimpleDateFormat _every_ time, should
>> there be some defaults that use DateFormat's
>> getDateInstance/getTimeInstance, i.e.:
>> new Date().formatDate() // see DateFormat#getDateInstance
>> new Date().formatTime() // see DateFormat#getTimeInstance
>> new Date().format() // or formatDateTime()
>>
>> Will have a simple implementation soon.
>>
>>
>> On Thu, Oct 2, 2008 at 6:56 PM, Guillaume Laforge <glaforge@...> wrote:
>>> Hi Tom,
>>>
>>> Sounds like a good addition.
>>>
>>> On Thu, Oct 2, 2008 at 8:49 PM, Tom Nichols <tmnichols@...> wrote:
>>>> This is probably a silly question, but why is there no Date.format(..)
>>>> GDK method? It would basically be a wrapper for SimpleDateFormat so
>>>> you could do this:
>>>>
>>>> new Date().format( 'yyyy-MM-dd' )
>>>> // returns 2008-10-02
>>>>
>>>> The same could be done for Calendar. Does something like this
>>>> seriously not already exist in the Groovy API?
>>>
>>> --
>>> Guillaume Laforge
>>> Groovy Project Manager
>>> G2One, Inc. Vice-President Technology
>>> http://www.g2one.com
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

http://xircles.codehaus.org/manage_email

Re: Date.format convenience methods

2008-10-06T07:19:51Z

Added a static Date.parse( pattern, input ) method in r.13699. Please
yell if I break anything -- A lot of unit tests seem to be failing for
me, even on a clean checkout -- Windows :(

Also, I'd like to get a tally of who thinks the name (or format)
should be changed for the "quickie" Date format methods. I'll
reiterate what stands right now:

date.dateString // uses DateFormat.getDateInstance( SHORT ) -
dd/MM/yy in en_UK
date.timeString // uses DateFormat.getTimeInstance( MEDIUM ) - HH:mm:ss
date.dateTimeString // uses DateFormat.getDateTimeInstance( SHORT, MEDIUM )

I think the other proposal was to use "format..." for all of the
method names like so:
date.formatDate()
date.formatTime()
date.formatDateTime()

Again, my main reason for choosing properties was to aid readability
in GStrings like
"Today's date is ${date.dateString}"
versus
"Today's date is ${date.formatDate()}"

but if the majority likes the "format.." convention better I can
switch it. If there isn't more significant discussion on this (or
argument on why there should be additional DGM methods) I'll consider
this done and close the JIRA issue.

Thanks!!
-Tom

On Thu, Oct 2, 2008 at 3:31 PM, Tom Nichols <tmnichols@...> wrote:

> Cool! Created issue here: http://jira.codehaus.org/browse/GROOVY-3066
>
> Two questions -
> 1. Should there be a complimentary "parse" method? Something like
> new Date( 'yyyy-MM-dd', someString )
>
> 2. In lieu of creating a new SimpleDateFormat _every_ time, should
> there be some defaults that use DateFormat's
> getDateInstance/getTimeInstance, i.e.:
> new Date().formatDate() // see DateFormat#getDateInstance
> new Date().formatTime() // see DateFormat#getTimeInstance
> new Date().format() // or formatDateTime()
>
> Will have a simple implementation soon.
>
>
> On Thu, Oct 2, 2008 at 6:56 PM, Guillaume Laforge <glaforge@...> wrote:
>> Hi Tom,
>>
>> Sounds like a good addition.
>>
>> On Thu, Oct 2, 2008 at 8:49 PM, Tom Nichols <tmnichols@...> wrote:
>>> This is probably a silly question, but why is there no Date.format(..)
>>> GDK method? It would basically be a wrapper for SimpleDateFormat so
>>> you could do this:
>>>
>>> new Date().format( 'yyyy-MM-dd' )
>>> // returns 2008-10-02
>>>
>>> The same could be done for Calendar. Does something like this
>>> seriously not already exist in the Groovy API?
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> G2One, Inc. Vice-President Technology
>> http://www.g2one.com
>>
>> ---------------------------------------------------------------------
>> 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

Re: Gant and Gradle

2008-10-06T04:25:25Z

Hi,

On Oct 4, 2008, at 11:07 AM, Russel Winder wrote:

<snip>

>
> Ever since Hans Dockter realized that he was not going to be able to
> build Gradle on Gant, but would have to have a new code base to
> achieve
> his goals, there has been a tension between the roles of Gant and
> Gradle. The core technical difference between Gant and Gradle is that
> Gant is simply a scripting systems whereas Gradle works with a DAG
> as do
> Make, Ant, Maven, SCons, etc.

Maven unfortunately does not use a DAG. This is another reason for
its inflexibility IMO.

> -- Gant is the odd one out here as a build
> framework, it does not build a data structure and reflect on that, it
> just executes code.

I would say that Gant uses an implicit DAG created at runtime. This
is what the 'depends' call is all about, isn't it. To me this is the
same way as Ant is doing things.

<snip>

> Gant is just a single jar and so is very lightweight whereas Gradle
> has
> a lot of dependencies and is relatively heavyweight.

This is a very valid point. Therefore we will put a lot of effort
into modularization soon.

<snip>

> Gradle can support many of the Ant task scripting things that Gant
> does
> but Gant is so much more lightweight than Gradle for doing this.

Definitely in terms of size and dependencies (see above). Do you also
see a difference in regard to coding?

>
> I am increasingly of the view that Gant should cease trying to be a
> build framework and leave this role to a rapidly evolving Gradle.
> Gant
> should instead reposition itself as a lightweight, embeddable Ant task
> scripting system. This is exactly how it is used in Grails.
> Embedding
> Gradle to do the Ant task scripting would for me be using too
> heavyweight a tool for the task at hand -- though having a Gradle
> rather
> than an Ant build for Grails and indeed Groovy might be a good move.

I think it is time for Groovy (I don't know the Grails build) to show
the world by its build the advantages of a Groovy based internal DSL :)

<snip>

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org

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

http://xircles.codehaus.org/manage_email

Re: Groovy as arithmetic expression evaluator?

2008-10-05T06:27:27Z

HamletDRC schrieb:
> Is there a way to cleanly add a static import for Math other than just
> appending "import static java.lang.Math.*" to the front of the groovyshell
> input?

ModuleNode#addStaticImportClass(importClassString, classNode)

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

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

http://xircles.codehaus.org/manage_email

RE: Gant and Gradle

2008-10-04T08:37:10Z

Russell:

Your proposal as to the futures of Gant and Gradle seems very reasonable
to me. I see the advantages of both, so long as they don't tend toward
each other in a vain attempt to be all things to all people.

Repositioning Gant as principally a scripting framework for Ant tasks
and Gradle as principally a build framework seems like a reasonable
development given the lightweight/heavyweight description you supply. Of
course, there will be folks who will be able to use Gant as a build
framework for simple cases, which is perfectly fine, too; just as there
are those who feel it is appropriate to use a business card to spread
jam on toast if a knife isn't ready to hand - and long may they do so!
:)

My $0.02.

David Sills

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

http://xircles.codehaus.org/manage_email

Re: [grails-user] Gant and Gradle

2008-10-04T08:29:47Z

This comparison sounds to me exactly like the one between Ant and Maven.
Maven and Ant both serve different purposes - Gant to me sounds just
like Ant while Gradle sounds like Maven.
The solution ? continue to develop both independently - Gant should
focus on being a build scripting tool while Gradle should focus on being
a project management tool.
Add support to running Gant scripts in Gradle - just like Maven supports
running Ant tasks.

Bashar
Russel Winder wrote:

> Please excuse the very wide initial circulation of this, but I want to
> make sure people are aware that there is a debate that might affect
> them. I suspect the best place for the debate is the Gant Users email
> list, so if people could be careful about which list they reply to when
> replying then people not interested in the debate will not get flooded
> -- i.e. please check carefully where you are sending replies if you
> reply to this email. Thanks.
>
> Ever since Hans Dockter realized that he was not going to be able to
> build Gradle on Gant, but would have to have a new code base to achieve
> his goals, there has been a tension between the roles of Gant and
> Gradle. The core technical difference between Gant and Gradle is that
> Gant is simply a scripting systems whereas Gradle works with a DAG as do
> Make, Ant, Maven, SCons, etc. -- Gant is the odd one out here as a build
> framework, it does not build a data structure and reflect on that, it
> just executes code.
>
> On and off over the last year (and very much on over the last couple of
> weeks) Hans and I have debated (privately) this issue of the tension
> between Gant and Gradle. Now though is the right time to open and widen
> this debate.
>
> In the Java milieu, Ant and Maven are the dominant build tools, though
> as an increasing number of people are realizing, using Groovy instead of
> XML as the build specification notation is a Big Win (tm) -- I get a
> continuous stream of emails (and I am sure Hans gets analogous emails)
> saying "Wow I just tried Gant and it is just so much nicer than Ant as
> Groovy is just so much better than XML". So the core question is how to
> make a Groovy-based build framework the dominant player in the Java
> world. Should we push both Gant and Gradle independently and see what
> happens or should we engineer things a little more so as to have a
> greater chance of success?
>
> There are many issues here, a few of which follow:
>
> Gant is just a scripting system and so doesn't really have all the
> infrastructure to do many of the things expected of a build framework,
> Gradle does. This implies Gradle is a better weapon for getting Groovy
> as the major build framework.
>
> Gant is just a single jar and so is very lightweight whereas Gradle has
> a lot of dependencies and is relatively heavyweight. Of course Gant is
> just a scripting replacement for the XML front end to Ant whereas
> Gradle is a complete Ivy-based build framework that supports management
> over the whole project lifecycle.
>
> People are increasingly asking for changes to Gant that can be achieved
> in a way, but really need DAG support which is already handled by
> Gradle.
>
> Gradle can support many of the Ant task scripting things that Gant does
> but Gant is so much more lightweight than Gradle for doing this.
>
> No-one seems to be interested in supporting Gant plugins for Eclipse,
> NetBeans or IntelliJ IDEA which is limiting its acceptance where IDEs
> are mandatory whereas work is in progress on Gradle plugins -- at least
> for Eclipse.
>
> There are many other issues but this will do for the present (to try and
> keep this email to some semblance of reasonable length :-)
>
> Where am I going with this?
>
> I am increasingly of the view that Gant should cease trying to be a
> build framework and leave this role to a rapidly evolving Gradle. Gant
> should instead reposition itself as a lightweight, embeddable Ant task
> scripting system. This is exactly how it is used in Grails. Embedding
> Gradle to do the Ant task scripting would for me be using too
> heavyweight a tool for the task at hand -- though having a Gradle rather
> than an Ant build for Grails and indeed Groovy might be a good move.
>
> Recently a number of people have made proposals for change to Gant and
> many of these are good proposals (especially the ones accompanied by
> patches :-) and I propose to evolve Gant with these proposals where they
> fit with Gant being just a lightweight Ant task scripting system. Where
> the changes are more to do with Gant becoming an improved build
> framework, I am contemplating not making the changes -- especially those
> where Gradle already does that which is needed.
>
> OK, I think this introduces the base issues, and this email is already
> long. I am therefore opening things to the floor to see what the Gant,
> Gradle, Groovy and Grails communities think about this. Should Gant and
> Gradle compete or should they be realigned and collaborate?
>
> Thanks.
>
>

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

http://xircles.codehaus.org/manage_email

Gant and Gradle

2008-10-04T02:07:37Z

Please excuse the very wide initial circulation of this, but I want to
make sure people are aware that there is a debate that might affect
them. I suspect the best place for the debate is the Gant Users email
list, so if people could be careful about which list they reply to when
replying then people not interested in the debate will not get flooded
-- i.e. please check carefully where you are sending replies if you
reply to this email. Thanks.

Ever since Hans Dockter realized that he was not going to be able to
build Gradle on Gant, but would have to have a new code base to achieve
his goals, there has been a tension between the roles of Gant and
Gradle. The core technical difference between Gant and Gradle is that
Gant is simply a scripting systems whereas Gradle works with a DAG as do
Make, Ant, Maven, SCons, etc. -- Gant is the odd one out here as a build
framework, it does not build a data structure and reflect on that, it
just executes code.

On and off over the last year (and very much on over the last couple of
weeks) Hans and I have debated (privately) this issue of the tension
between Gant and Gradle. Now though is the right time to open and widen
this debate.

In the Java milieu, Ant and Maven are the dominant build tools, though
as an increasing number of people are realizing, using Groovy instead of
XML as the build specification notation is a Big Win (tm) -- I get a
continuous stream of emails (and I am sure Hans gets analogous emails)
saying "Wow I just tried Gant and it is just so much nicer than Ant as
Groovy is just so much better than XML". So the core question is how to
make a Groovy-based build framework the dominant player in the Java
world. Should we push both Gant and Gradle independently and see what
happens or should we engineer things a little more so as to have a
greater chance of success?

There are many issues here, a few of which follow:

Gant is just a scripting system and so doesn't really have all the
infrastructure to do many of the things expected of a build framework,
Gradle does. This implies Gradle is a better weapon for getting Groovy
as the major build framework.

Gant is just a single jar and so is very lightweight whereas Gradle has
a lot of dependencies and is relatively heavyweight. Of course Gant is
just a scripting replacement for the XML front end to Ant whereas
Gradle is a complete Ivy-based build framework that supports management
over the whole project lifecycle.

People are increasingly asking for changes to Gant that can be achieved
in a way, but really need DAG support which is already handled by
Gradle.

Gradle can support many of the Ant task scripting things that Gant does
but Gant is so much more lightweight than Gradle for doing this.

No-one seems to be interested in supporting Gant plugins for Eclipse,
NetBeans or IntelliJ IDEA which is limiting its acceptance where IDEs
are mandatory whereas work is in progress on Gradle plugins -- at least
for Eclipse.

There are many other issues but this will do for the present (to try and
keep this email to some semblance of reasonable length :-)

Where am I going with this?

I am increasingly of the view that Gant should cease trying to be a
build framework and leave this role to a rapidly evolving Gradle. Gant
should instead reposition itself as a lightweight, embeddable Ant task
scripting system. This is exactly how it is used in Grails. Embedding
Gradle to do the Ant task scripting would for me be using too
heavyweight a tool for the task at hand -- though having a Gradle rather
than an Ant build for Grails and indeed Groovy might be a good move.

Recently a number of people have made proposals for change to Gant and
many of these are good proposals (especially the ones accompanied by
patches :-) and I propose to evolve Gant with these proposals where they
fit with Gant being just a lightweight Ant task scripting system. Where
the changes are more to do with Gant becoming an improved build
framework, I am contemplating not making the changes -- especially those
where Gradle already does that which is needed.

OK, I think this introduces the base issues, and this email is already
long. I am therefore opening things to the floor to see what the Gant,
Gradle, Groovy and Grails communities think about this. Should Gant and
Gradle compete or should they be realigned and collaborate?

Thanks.

--
Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment

Re: Groovy as arithmetic expression evaluator?

2008-10-04T01:12:33Z

Hi Hamlet,

You can use the technique illustrated at the bottom of this class:
http://code.google.com/p/testngroove/source/browse/trunk/src/main/org/codehaus/groovy/testng/GroovyTestNG.java#205

And use module.addStaticImportClass()

On Sat, Oct 4, 2008 at 4:02 AM, HamletDRC <hamletdrc@...> wrote:

>
> Is there a way to cleanly add a static import for Math other than just
> appending "import static java.lang.Math.*" to the front of the groovyshell
> input?
>
>
>
> glaforge wrote:
>>
>> Hi Hamlet,
>>
>> Nice work!
>> I'm wondering if / where we could provide such specific shells /
>> classloaders in Groovy.
>> That could be interesting, and people would be happy to reuse these.
>> A little remark, perhaps you could allow static imports for Math
>> constants? (instead of having to do Math.PI, etc)
>>
>> On Thu, Sep 18, 2008 at 5:40 AM, HamletDRC <hamletdrc@...> wrote:
>>>
>>> Alright, thanks for the help everyone. I have a prototype working in
>>> Groovy,
>>> although for my work I will need to re-write the code in Java tomorrow.
>>> Whatever.
>>>
>>> In case you're interested, the unit tests are here:
>>> http://svn.assembla.com/svn/SampleCode/gep/tests/gep/ArithmeticShellTest.groovy
>>>
>>> All of the following passes:
>>> ArithmeticShell shell = new ArithmeticShell()
>>> assertEquals(2.9073548971824276E135, shell.evaluate("((6L / 2f) - 1) **
>>> 4.5e2"))
>>> assertEquals(-6.816387600233341, shell.evaluate("10 * Math.sin(15/-20)"))
>>> assertEquals(74.17310622494026,
>>> shell.evaluate("80*Math.E**(-(+(11++/40)**2))"))
>>> assertEquals(2147483646, shell.evaluate("Integer.MAX_VALUE - ++2%2"))
>>> assertEquals(6, shell.evaluate("++(5)"))
>>> assertEquals(0, shell.evaluate("5 < 4 ? 1 : 0"))
>>> assertEquals(0, shell.evaluate("5 != 4 ? 0 : 1 "))
>>>
>>> While the rest fails:
>>> ArithmeticShell shell = new ArithmeticShell()
>>> shouldFail(SecurityException) {
>>> shell.evaluate("Double.valueOf(\"5\")")
>>> }
>>> shouldFail(SecurityException) {
>>> shell.evaluate("import java.swing.JLabel;5")
>>> }
>>> shouldFail(SecurityException) {
>>> shell.evaluate("def x = 5+3;x.toString()")
>>> }
>>> shouldFail(SecurityException) {
>>> shell.evaluate("new File();Double.valueOf(\"5\")")
>>> }
>>>
>>> The source code is here... any tips (especially regarding security) are
>>> encouraged:
>>> http://svn.assembla.com/svn/SampleCode/gep/src/gep/ArithmeticShell.groovy
>>>
>>> In the end, I ended up hooking into the compiler during the
>>> SEMANTIC_ANALYSIS phase because it seemed to offer my more type
>>> information
>>> in the AST than when originally walked the AST in the CONVERSION phase.
>>>
>>> Does anyone have any use for this ArithmeticShell object? I can clean it
>>> up
>>> and create a jar/patch or whatever.
>>>
>>> Thanks everyone, this was the most enjoyable day I've had in a while.
>>>
>>> -- Hamlet D'Arcy
>>>
>>>
>>>
>>> Jochen Theodorou wrote:
>>>>
>>>> Roshan Dawrani schrieb:
>>>>> Right. Thanks for pointing that out. I noticed it too in your earlier
>>>>> reply when you called main() like clazz.main(null).
>>>>>
>>>>> However, generally GroovyClassLoader.parseClass() is an approach to
>>>>> call
>>>>> groovy code from Java, isn't it? Would such an approach be useful from
>>>>> groovy to groovy also in some scenario?
>>>>
>>>> parseClass is a way to call the compiler and load the compiled classes
>>>> without setting up a complete environment. Also it offers extended
>>>> abilities, like hooking into the compilation process itself. GroovyShell
>>>> is more or less a simplified interface to GroovyClassLoader. If this
>>>> doesn't do what you need, then you need to bother with
>>>> GroovyClassLoader. It doesn't matter if you are calling from Java or
>>>> Groovy.
>>>>
>>>>> Since in thread code, I saw GroovyClassLoader getting used all along, I
>>>>> assumed that calling code is Java. It is just for a little convenience
>>>>> that I had written the calling code in groovy. No explicit javac step
>>>>> necessary! Just write and experiment! Very helpful!
>>>>
>>>> if the code contains a def like in the example from Roshan Dawrani, then
>>>> it sure is Groovy code ;)
>>>>
>>>> bye blackdrag
>>>>
>>>> --
>>>> Jochen "blackdrag" Theodorou
>>>> The Groovy Project Tech Lead (http://groovy.codehaus.org)
>>>> http://blackdragsview.blogspot.com/
>>>> http://www.g2one.com/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> -----
>>> --
>>> Hamlet D'Arcy
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Groovy-as-arithmetic-expression-evaluator--tp19459935p19545385.html
>>> Sent from the groovy - user mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> G2One, Inc. Vice-President Technology
>> http://www.g2one.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>
>
> -----
> --
> Hamlet D'Arcy
>
> --
> View this message in context: http://www.nabble.com/Groovy-as-arithmetic-expression-evaluator--tp19459935p19808379.html
> Sent from the groovy - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

Re: Groovy as arithmetic expression evaluator?

2008-10-03T20:47:13Z

There's the concept of mix-ins, but they're not in general release yet (I think).

~~ Robert.

HamletDRC wrote:

> Is there a way to cleanly add a static import for Math other than just
> appending "import static java.lang.Math.*" to the front of the groovyshell
> input?
>
>
>
> glaforge wrote:
>> Hi Hamlet,
>>
>> Nice work!
>> I'm wondering if / where we could provide such specific shells /
>> classloaders in Groovy.
>> That could be interesting, and people would be happy to reuse these.
>> A little remark, perhaps you could allow static imports for Math
>> constants? (instead of having to do Math.PI, etc)
>>
>> On Thu, Sep 18, 2008 at 5:40 AM, HamletDRC <hamletdrc@...> wrote:
>>> Alright, thanks for the help everyone. I have a prototype working in
>>> Groovy,
>>> although for my work I will need to re-write the code in Java tomorrow.
>>> Whatever.
>>>
>>> In case you're interested, the unit tests are here:
>>> http://svn.assembla.com/svn/SampleCode/gep/tests/gep/ArithmeticShellTest.groovy
>>>
>>> All of the following passes:
>>> ArithmeticShell shell = new ArithmeticShell()
>>> assertEquals(2.9073548971824276E135, shell.evaluate("((6L / 2f) - 1) **
>>> 4.5e2"))
>>> assertEquals(-6.816387600233341, shell.evaluate("10 * Math.sin(15/-20)"))
>>> assertEquals(74.17310622494026,
>>> shell.evaluate("80*Math.E**(-(+(11++/40)**2))"))
>>> assertEquals(2147483646, shell.evaluate("Integer.MAX_VALUE - ++2%2"))
>>> assertEquals(6, shell.evaluate("++(5)"))
>>> assertEquals(0, shell.evaluate("5 < 4 ? 1 : 0"))
>>> assertEquals(0, shell.evaluate("5 != 4 ? 0 : 1 "))
>>>
>>> While the rest fails:
>>> ArithmeticShell shell = new ArithmeticShell()
>>> shouldFail(SecurityException) {
>>> shell.evaluate("Double.valueOf(\"5\")")
>>> }
>>> shouldFail(SecurityException) {
>>> shell.evaluate("import java.swing.JLabel;5")
>>> }
>>> shouldFail(SecurityException) {
>>> shell.evaluate("def x = 5+3;x.toString()")
>>> }
>>> shouldFail(SecurityException) {
>>> shell.evaluate("new File();Double.valueOf(\"5\")")
>>> }
>>>
>>> The source code is here... any tips (especially regarding security) are
>>> encouraged:
>>> http://svn.assembla.com/svn/SampleCode/gep/src/gep/ArithmeticShell.groovy
>>>
>>> In the end, I ended up hooking into the compiler during the
>>> SEMANTIC_ANALYSIS phase because it seemed to offer my more type
>>> information
>>> in the AST than when originally walked the AST in the CONVERSION phase.
>>>
>>> Does anyone have any use for this ArithmeticShell object? I can clean it
>>> up
>>> and create a jar/patch or whatever.
>>>
>>> Thanks everyone, this was the most enjoyable day I've had in a while.
>>>
>>> -- Hamlet D'Arcy
>>>
>>>
>>>
>>> Jochen Theodorou wrote:
>>>> Roshan Dawrani schrieb:
>>>>> Right. Thanks for pointing that out. I noticed it too in your earlier
>>>>> reply when you called main() like clazz.main(null).
>>>>>
>>>>> However, generally GroovyClassLoader.parseClass() is an approach to
>>>>> call
>>>>> groovy code from Java, isn't it? Would such an approach be useful from
>>>>> groovy to groovy also in some scenario?
>>>> parseClass is a way to call the compiler and load the compiled classes
>>>> without setting up a complete environment. Also it offers extended
>>>> abilities, like hooking into the compilation process itself. GroovyShell
>>>> is more or less a simplified interface to GroovyClassLoader. If this
>>>> doesn't do what you need, then you need to bother with
>>>> GroovyClassLoader. It doesn't matter if you are calling from Java or
>>>> Groovy.
>>>>
>>>>> Since in thread code, I saw GroovyClassLoader getting used all along, I
>>>>> assumed that calling code is Java. It is just for a little convenience
>>>>> that I had written the calling code in groovy. No explicit javac step
>>>>> necessary! Just write and experiment! Very helpful!
>>>> if the code contains a def like in the example from Roshan Dawrani, then
>>>> it sure is Groovy code ;)
>>>>
>>>> bye blackdrag
>>>>
>>>> --
>>>> Jochen "blackdrag" Theodorou
>>>> The Groovy Project Tech Lead (http://groovy.codehaus.org)
>>>> http://blackdragsview.blogspot.com/
>>>> http://www.g2one.com/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>
>>> -----
>>> --
>>> Hamlet D'Arcy
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Groovy-as-arithmetic-expression-evaluator--tp19459935p19545385.html
>>> Sent from the groovy - user mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> G2One, Inc. Vice-President Technology
>> http://www.g2one.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>
>
> -----
> --
> Hamlet D'Arcy
>

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

http://xircles.codehaus.org/manage_email

Re: Groovy as arithmetic expression evaluator?

2008-10-03T19:02:20Z

Is there a way to cleanly add a static import for Math other than just appending "import static java.lang.Math.*" to the front of the groovyshell input?

glaforge wrote:

Hi Hamlet,

Nice work!
I'm wondering if / where we could provide such specific shells /
classloaders in Groovy.
That could be interesting, and people would be happy to reuse these.
A little remark, perhaps you could allow static imports for Math
constants? (instead of having to do Math.PI, etc)

On Thu, Sep 18, 2008 at 5:40 AM, HamletDRC <hamletdrc@gmail.com> wrote:
>
> Alright, thanks for the help everyone. I have a prototype working in Groovy,
> although for my work I will need to re-write the code in Java tomorrow.
> Whatever.
>
> In case you're interested, the unit tests are here:
> http://svn.assembla.com/svn/SampleCode/gep/tests/gep/ArithmeticShellTest.groovy
>
> All of the following passes:
> ArithmeticShell shell = new ArithmeticShell()
> assertEquals(2.9073548971824276E135, shell.evaluate("((6L / 2f) - 1) **
> 4.5e2"))
> assertEquals(-6.816387600233341, shell.evaluate("10 * Math.sin(15/-20)"))
> assertEquals(74.17310622494026,
> shell.evaluate("80*Math.E**(-(+(11++/40)**2))"))
> assertEquals(2147483646, shell.evaluate("Integer.MAX_VALUE - ++2%2"))
> assertEquals(6, shell.evaluate("++(5)"))
> assertEquals(0, shell.evaluate("5 < 4 ? 1 : 0"))
> assertEquals(0, shell.evaluate("5 != 4 ? 0 : 1 "))
>
> While the rest fails:
> ArithmeticShell shell = new ArithmeticShell()
> shouldFail(SecurityException) {
> shell.evaluate("Double.valueOf(\"5\")")
> }
> shouldFail(SecurityException) {
> shell.evaluate("import java.swing.JLabel;5")
> }
> shouldFail(SecurityException) {
> shell.evaluate("def x = 5+3;x.toString()")
> }
> shouldFail(SecurityException) {
> shell.evaluate("new File();Double.valueOf(\"5\")")
> }
>
> The source code is here... any tips (especially regarding security) are
> encouraged:
> http://svn.assembla.com/svn/SampleCode/gep/src/gep/ArithmeticShell.groovy
>
> In the end, I ended up hooking into the compiler during the
> SEMANTIC_ANALYSIS phase because it seemed to offer my more type information
> in the AST than when originally walked the AST in the CONVERSION phase.
>
> Does anyone have any use for this ArithmeticShell object? I can clean it up
> and create a jar/patch or whatever.
>
> Thanks everyone, this was the most enjoyable day I've had in a while.
>
> -- Hamlet D'Arcy
>
>
>
> Jochen Theodorou wrote:
>>
>> Roshan Dawrani schrieb:
>>> Right. Thanks for pointing that out. I noticed it too in your earlier
>>> reply when you called main() like clazz.main(null).
>>>
>>> However, generally GroovyClassLoader.parseClass() is an approach to call
>>> groovy code from Java, isn't it? Would such an approach be useful from
>>> groovy to groovy also in some scenario?
>>
>> parseClass is a way to call the compiler and load the compiled classes
>> without setting up a complete environment. Also it offers extended
>> abilities, like hooking into the compilation process itself. GroovyShell
>> is more or less a simplified interface to GroovyClassLoader. If this
>> doesn't do what you need, then you need to bother with
>> GroovyClassLoader. It doesn't matter if you are calling from Java or
>> Groovy.
>>
>>> Since in thread code, I saw GroovyClassLoader getting used all along, I
>>> assumed that calling code is Java. It is just for a little convenience
>>> that I had written the calling code in groovy. No explicit javac step
>>> necessary! Just write and experiment! Very helpful!
>>
>> if the code contains a def like in the example from Roshan Dawrani, then
>> it sure is Groovy code ;)
>>
>> bye blackdrag
>>
>> --
>> Jochen "blackdrag" Theodorou
>> The Groovy Project Tech Lead (http://groovy.codehaus.org)
>> http://blackdragsview.blogspot.com/
>> http://www.g2one.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>
>
> -----
> --
> Hamlet D'Arcy
>
> --
> View this message in context: http://www.nabble.com/Groovy-as-arithmetic-expression-evaluator--tp19459935p19545385.html
> Sent from the groovy - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

http://xircles.codehaus.org/manage_email

--
Hamlet D'Arcy

Re: Date.format convenience methods

2008-10-03T17:31:21Z

On Fri, Oct 3, 2008 at 7:39 PM, Paul King <paulk@...> wrote:

>>> * Getting the time of the first or last second of a day eg input Date,
>>> get
>>> back same date but with 23:59:59 as the time, or 00:00:00 to get start of
>>> the day
>>
>> Adding or subtracting 1.second doesn't do this?
>
> I think he is referring to something like .midnight()
> which would take a given date and effectively zero off
> hours, minutes and seconds (in the current timezone).
> You could then add or subtract 1.

I see. I'd still argue cases like this are better suited for a mixin,
or category. It's not too difficult to do with plain
GregorianCalendar either.

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

http://xircles.codehaus.org/manage_email

Re: Date.format convenience methods

2008-10-03T16:39:52Z

Tom Nichols wrote:
>> * Getting the time of the first or last second of a day eg input Date, get
>> back same date but with 23:59:59 as the time, or 00:00:00 to get start of
>> the day
>
> Adding or subtracting 1.second doesn't do this?

I think he is referring to something like .midnight()
which would take a given date and effectively zero off
hours, minutes and seconds (in the current timezone).
You could then add or subtract 1.

Paul.

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

http://xircles.codehaus.org/manage_email

Re: Cannot use Map to "extend" a Java inner class

2008-10-03T16:03:36Z

Yes, I have a patch somewhere which at least partially fixes this.
Didn't get time to test it properly, so saved it as a patch locally
before rolling back to work on other things. I'll see if I can find it.

Paul.

Roshan Dawrani wrote:

> Hi,
> The source code that groovy is internally generating for the proxy class
> (for the map extending the inner class "TestInner.Inner" in the groovy
> code) is as follows:
>
> ---------------------------------------------------------------------------------------------------------
> class TestInner$Inner_groovyProxy extends TestInner$Inner {
> private closureMap
> TestInner$Inner_groovyProxy(map) {
> super()
> this.closureMap = map
> }
> java.lang.String debug() { this.@closureMap['debug'] () }
> }
> new TestInner$Inner_groovyProxy(map)
>
> ---------------------------------------------------------------------------------------------------------
>
> And it is giving a compilation error as the name of the class has a "$"
> symbol in it. If the maps can extend classes/abstract classes to provide
> the implementation and inner classes need to be supported, then naming
> of the inner classes needs to be handled appropriately.
>
> rgds,
> Roshan
>
>
> On Fri, Oct 3, 2008 at 10:55 PM, Mingfai <mingfai.ma
> <http://mingfai.ma>@gmail.com <http://gmail.com>> wrote:
>
> tried. it doesn't work, too.
>
> http://jira.codehaus.org/browse/GROOVY-3068
>
>
>
> On Sat, Oct 4, 2008 at 1:07 AM, Guillaume Laforge
> <glaforge@... <mailto:glaforge@...>> wrote:
>
> At first sight, it looks like a bug, worth a JIRA.
> I haven't tried, but perhaps a workaround could be to try
> aliasing the
> import of that inner class with import foo.TestInner.Inner as
> MyInner,
> and do def inner1 = [debug: { "outer debug 1" }] as MyInner.
> Dunno if
> that works.
>
> On Fri, Oct 3, 2008 at 7:03 PM, Mingfai <mingfai.ma
> <http://mingfai.ma>@gmail.com <http://gmail.com>> wrote:
> > i'm not sure if using a Map to "extend" a Java class is an
> officially
> > supported feature anyway. The doc only say it can be used to
> implement
> > interface.
> >
> > Say, for the following Java:
> > public class TestInner {
> > public String debug(){ return "outer debug"; }
> >
> > public class Inner {
> > public String debug(){ return "inner debug"; }
> > }
> > }
> >
> > The following does work:
> >
> > def inner1 = ['debug':{return "outer debug 1"}] as TestInner
> > println inner1.debug()
> >
> > But not :
> > def inner2 = ['debug':{return "inner debug 1"}] as
> TestInner.Inner
> > println inner2.debug()
> >
> > There is compilation error.
> > Caught:
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Error
> > casting map to TestInner$Inner, Reason: Error creating proxy:
> startup
> > failed, Script1.groovy: 1: unexpected token: $ @ line 1,
> column 16.
> > 1 error
> >
> > JIRA it as bug or request for new feature? :-)
> >
> > regards,
> > mingfai
> >
> >
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> G2One, Inc. Vice-President Technology
> http://www.g2one.com
>
> ---------------------------------------------------------------------
> 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

Re: Closure does not have scope precedent over local method?

2008-10-03T11:00:50Z

Hi,
I have now opened an issue for the issue relating to a closure parameter not having scope precedent over local method - http://jira.codehaus.org/browse/GROOVY-3069

rgds,
Roshan

On Thu, Oct 2, 2008 at 9:30 AM, Roshan Dawrani <roshandawrani@...> wrote:

Hi Tom,
Since you originally raised this issue, wanted to check with you if you would like to fill an issue for it or you would like me to fill one?
rgds,
Roshan

On Thu, Oct 2, 2008 at 12:04 AM, Jochen Theodorou <blackdrag@...> wrote:

Ladislav Thon schrieb:

> So instead I would like other users here telling me what they
expect when
> they see code like:
>
> [...]
>>
>> private String selectSql() {return 'local method'}
>>
>> public String returnSql(String id, Closure selectSql) {
>> return "${selectSql()}"
>> }
>> }
>
> so what do others think?

Intuitively, I expected that the closure would have been called.
Whereas if I wanted to call the method, I would haven had to
disambiguate using this.selectSql().

Agree. At least the behavior is consistent with a direct call return selectSql(), but really counter-intuitive. All common precedence resolution strategies I can think of now, both lexical (static) or dynamic, would resolve to the parameter. Don't know anything about implementation of Groovy (although I would like to play with the source code someday, as it interests me quite a lot).

since we have at last 3 pro and no con atm I suggest that you or the original poster fill an issue for it... if it is not filled yet... I am in the process of catching up with my emails, so maybe there is one already

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

http://www.g2one.com/

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

http://xircles.codehaus.org/manage_email

Re: Cannot use Map to "extend" a Java inner class

2008-10-03T10:34:05Z

Hi,
The source code that groovy is internally generating for the proxy class (for the map extending the inner class "TestInner.Inner" in the groovy code) is as follows:

---------------------------------------------------------------------------------------------------------
class TestInner$Inner_groovyProxy extends TestInner$Inner {
    private closureMap
    TestInner$Inner_groovyProxy(map) {
        super()
        this.closureMap = map
    }
    java.lang.String debug() { this.@closureMap['debug'] ()    }
}
new TestInner$Inner_groovyProxy(map)

---------------------------------------------------------------------------------------------------------

And it is giving a compilation error as the name of the class has a "$" symbol in it. If the maps can extend classes/abstract classes to provide the implementation and inner classes need to be supported, then naming of the inner classes needs to be handled appropriately.

rgds,
Roshan

On Fri, Oct 3, 2008 at 10:55 PM, Mingfai <mingfai.ma@gmail.com> wrote:

tried. it doesn't work, too.

http://jira.codehaus.org/browse/GROOVY-3068

On Sat, Oct 4, 2008 at 1:07 AM, Guillaume Laforge <glaforge@...> wrote:

At first sight, it looks like a bug, worth a JIRA.
I haven't tried, but perhaps a workaround could be to try aliasing the
import of that inner class with import foo.TestInner.Inner as MyInner,
and do def inner1 = [debug: { "outer debug 1" }] as MyInner. Dunno if
that works.

On Fri, Oct 3, 2008 at 7:03 PM, Mingfai <mingfai.ma@gmail.com> wrote:
> i'm not sure if using a Map to "extend" a Java class is an officially
> supported feature anyway. The doc only say it can be used to implement
> interface.
>
> Say, for the following Java:
> public class TestInner {
> public String debug(){ return "outer debug"; }
>
> public class Inner {
> public String debug(){ return "inner debug"; }
> }
> }
>
> The following does work:
>
> def inner1 = ['debug':{return "outer debug 1"}] as TestInner
> println inner1.debug()
>
> But not :
> def inner2 = ['debug':{return "inner debug 1"}] as TestInner.Inner
> println inner2.debug()
>
> There is compilation error.
> Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Error
> casting map to TestInner$Inner, Reason: Error creating proxy: startup
> failed, Script1.groovy: 1: unexpected token: $ @ line 1, column 16.
> 1 error
>
> JIRA it as bug or request for new feature? :-)
>
> regards,
> mingfai
>
>

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

http://xircles.codehaus.org/manage_email

Re: Cannot use Map to "extend" a Java inner class

2008-10-03T10:25:55Z

tried. it doesn't work, too.

http://jira.codehaus.org/browse/GROOVY-3068

On Sat, Oct 4, 2008 at 1:07 AM, Guillaume Laforge <glaforge@...> wrote:

At first sight, it looks like a bug, worth a JIRA.
I haven't tried, but perhaps a workaround could be to try aliasing the
import of that inner class with import foo.TestInner.Inner as MyInner,
and do def inner1 = [debug: { "outer debug 1" }] as MyInner. Dunno if
that works.

On Fri, Oct 3, 2008 at 7:03 PM, Mingfai <mingfai.ma@gmail.com> wrote:
> i'm not sure if using a Map to "extend" a Java class is an officially
> supported feature anyway. The doc only say it can be used to implement
> interface.
>
> Say, for the following Java:
> public class TestInner {
> public String debug(){ return "outer debug"; }
>
> public class Inner {
> public String debug(){ return "inner debug"; }
> }
> }
>
> The following does work:
>
> def inner1 = ['debug':{return "outer debug 1"}] as TestInner
> println inner1.debug()
>
> But not :
> def inner2 = ['debug':{return "inner debug 1"}] as TestInner.Inner
> println inner2.debug()
>
> There is compilation error.
> Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Error
> casting map to TestInner$Inner, Reason: Error creating proxy: startup
> failed, Script1.groovy: 1: unexpected token: $ @ line 1, column 16.
> 1 error
>
> JIRA it as bug or request for new feature? :-)
>
> regards,
> mingfai
>
>

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

http://xircles.codehaus.org/manage_email

Re: Cannot use Map to "extend" a Java inner class

2008-10-03T10:07:56Z

At first sight, it looks like a bug, worth a JIRA.
I haven't tried, but perhaps a workaround could be to try aliasing the
import of that inner class with import foo.TestInner.Inner as MyInner,
and do def inner1 = [debug: { "outer debug 1" }] as MyInner. Dunno if
that works.

On Fri, Oct 3, 2008 at 7:03 PM, Mingfai <mingfai.ma@...> wrote:

> i'm not sure if using a Map to "extend" a Java class is an officially
> supported feature anyway. The doc only say it can be used to implement
> interface.
>
> Say, for the following Java:
> public class TestInner {
> public String debug(){ return "outer debug"; }
>
> public class Inner {
> public String debug(){ return "inner debug"; }
> }
> }
>
> The following does work:
>
> def inner1 = ['debug':{return "outer debug 1"}] as TestInner
> println inner1.debug()
>
> But not :
> def inner2 = ['debug':{return "inner debug 1"}] as TestInner.Inner
> println inner2.debug()
>
> There is compilation error.
> Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Error
> casting map to TestInner$Inner, Reason: Error creating proxy: startup
> failed, Script1.groovy: 1: unexpected token: $ @ line 1, column 16.
> 1 error
>
> JIRA it as bug or request for new feature? :-)
>
> regards,
> mingfai
>
>

Cannot use Map to "extend" a Java inner class

2008-10-03T10:03:55Z

i'm not sure if using a Map to "extend" a Java class is an officially supported feature anyway. The doc only say it can be used to implement interface.

Say, for the following Java:
public class TestInner {
   public String debug(){ return "outer debug"; }

    public class Inner {
        public String debug(){ return "inner debug"; }
    }
}

The following does work:

def inner1 = ['debug':{return "outer debug 1"}] as TestInner
println inner1.debug()

But not :
def inner2 = ['debug':{return "inner debug 1"}] as TestInner.Inner
println inner2.debug()

There is compilation error.
Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Error casting map to TestInner$Inner, Reason: Error creating proxy: startup failed, Script1.groovy: 1: unexpected token: $ @ line 1, column 16.
1 error

JIRA it as bug or request for new feature? :-)

regards,
mingfai

Re: London GGUG meeting last evening -- Groovy strategy for parallelism

2008-10-03T09:36:08Z

Peter Ledbrook-2 wrote:

I've been thinking about this, and actually if Groovy were to become a
real contender for writing Swing applications, then I think the higher
level abstractions would be worth the effort. There's nothing like a
Swing application for threading issues :) Although such things may be
solved with something like the Groovy Actors library rather than
JSR166y.

We do have some abstractions provided by Swing(X)Builder already (edt, doLater, doOutside, withworker), but I agree that an actor based library would boost concurrent programming, not just for Swing apps :-)

Peter Ledbrook-2 wrote:

Also, I don't know what the results of JSR166y look like, but if it's
not particularly easy to use then "easy parallelism with Groovy" would
be a good selling point in general.

See here for some examples http://groovy.dzone.com/news/concurrency-jsr-166y-meets-gro