Mingfai | 1 Mar 12:11 2009
Picon

Re: [groovy-dev] <at> Use ast transformation

just recalled this thread.

we could avoid having too many ways to do things by....
  obsolete the use(XXXX){} usage which becomes ugly in compare to annotation!

regards,
mingfai

On Mon, Oct 13, 2008 at 9:36 PM, Guillaume Laforge <glaforge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
My feeling on <at> Use is that if it's just another notation for use() {},
I don't see too much the need for it.
In the end, Groovy would become Perl if we offer too many ways to do
something we can already do differently :-(

On Mon, Oct 13, 2008 at 3:15 PM, Guillaume Laforge <glaforge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> What's wrong with lexical scoping?
> On the contrary, it seems like a desirable feature.
>
> On Mon, Oct 13, 2008 at 2:58 PM, Dierk König <dierk.koenig-vS5zOjhOW+wAvxtiuMwx3w@public.gmane.org> wrote:
>> +1
>>
>> Dierk
>>
>> P.S. as long as this doesn't mean lexical scoping ;-)
>>
>> | -----Original Message-----
>> | From: Alex Tkachman [mailto:alex.tkachman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
>> | Sent: Montag, 13. Oktober 2008 14:16
>> | To: dev-i9PBDF1N6cyNMHH3USLmrg@public.gmane.orgus.org
>> | Subject: [groovy-dev] <at> Use ast transformation
>> |
>> | Any objections for adding <at> Use ast transformation, which
>> | applies listed categories to either each method in the class
>> | or particular method or constructor
>> |
>> | <at> Use(CategoryForClass_1, CategoryForClass_2) class TestClass {
>> |
>> |     <at> Use(CategoryForMethod)
>> |    def method () {
>> |         //
>> |    }
>> | }
>> |
>> |
>>
>> ---------------------------------------------------------------------
>> 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
>



--
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



Guillaume Laforge | 1 Mar 12:22 2009

Re: [groovy-dev] <at> Use ast transformation

This is unfortunately often a question of taste!

And doing this has several drawbacks:
- breaking backward compatibility with all those using use()
- a  <at> Use annotation would be less granular than use(), since it'd be
just at method level as a minimum grain, whereas you can just use
use() anywhere for even just one statement, and even nest use() within
other use()

On Sun, Mar 1, 2009 at 12:11, Mingfai <mingfai.ma@...> wrote:
> just recalled this thread.
>
> we could avoid having too many ways to do things by....
>   obsolete the use(XXXX){} usage which becomes ugly in compare to
> annotation!
>
> regards,
> mingfai
>
> On Mon, Oct 13, 2008 at 9:36 PM, Guillaume Laforge <glaforge@...>
> wrote:
>>
>> My feeling on  <at> Use is that if it's just another notation for use() {},
>> I don't see too much the need for it.
>> In the end, Groovy would become Perl if we offer too many ways to do
>> something we can already do differently :-(
>>
>> On Mon, Oct 13, 2008 at 3:15 PM, Guillaume Laforge <glaforge@...>
>> wrote:
>> > What's wrong with lexical scoping?
>> > On the contrary, it seems like a desirable feature.
>> >
>> > On Mon, Oct 13, 2008 at 2:58 PM, Dierk König <dierk.koenig@...>
>> > wrote:
>> >> +1
>> >>
>> >> Dierk
>> >>
>> >> P.S. as long as this doesn't mean lexical scoping ;-)
>> >>
>> >> | -----Original Message-----
>> >> | From: Alex Tkachman [mailto:alex.tkachman@...]
>> >> | Sent: Montag, 13. Oktober 2008 14:16
>> >> | To: dev@...
>> >> | Subject: [groovy-dev]  <at> Use ast transformation
>> >> |
>> >> | Any objections for adding  <at> Use ast transformation, which
>> >> | applies listed categories to either each method in the class
>> >> | or particular method or constructor
>> >> |
>> >> |  <at> Use(CategoryForClass_1, CategoryForClass_2) class TestClass {
>> >> |
>> >> |     <at> Use(CategoryForMethod)
>> >> |    def method () {
>> >> |         //
>> >> |    }
>> >> | }
>> >> |
>> >> |
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>> >
>>
>>
>>
>> --
>> 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
>>
>>
>
>

--

-- 
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

    http://xircles.codehaus.org/manage_email

Chanwit Kaewkasi | 1 Mar 12:30 2009
Picon

Re: [groovy-dev] <at> Use ast transformation

Hi,

On Sun, Mar 1, 2009 at 6:22 PM, Guillaume Laforge <glaforge@...> wrote:
> - a  <at> Use annotation would be less granular than use(), since it'd be
> just at method level as a minimum grain, whereas you can just use
> use() anywhere for even just one statement, and even nest use() within
> other use()

I second this. The annotation will limit the ways of using "use".

--

-- 
Chanwit Kaewkasi
PhD Candidate,
Centre for Novel Computing
School of Computer Science
The University of Manchester
Oxford Road
Manchester
M13 9PL, UK

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

    http://xircles.codehaus.org/manage_email

Mingfai | 1 Mar 12:36 2009
Picon

Re: [groovy-dev] <at> Use ast transformation

let's vote: http://jira.codehaus.org/browse/GROOVY-3387


On Sun, Mar 1, 2009 at 7:22 PM, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org> wrote:
This is unfortunately often a question of taste!

And doing this has several drawbacks:
- breaking backward compatibility with all those using use()
- a <at> Use annotation would be less granular than use(), since it'd be
just at method level as a minimum grain, whereas you can just use
use() anywhere for even just one statement, and even nest use() within
other use()


On Sun, Mar 1, 2009 at 12:11, Mingfai <mingfai.ma <at> gmail.com> wrote:
> just recalled this thread.
>
> we could avoid having too many ways to do things by....
>   obsolete the use(XXXX){} usage which becomes ugly in compare to
> annotation!
>
> regards,
> mingfai
>
> On Mon, Oct 13, 2008 at 9:36 PM, Guillaume Laforge <glaforge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
>>
>> My feeling on <at> Use is that if it's just another notation for use() {},
>> I don't see too much the need for it.
>> In the end, Groovy would become Perl if we offer too many ways to do
>> something we can already do differently :-(
>>
>> On Mon, Oct 13, 2008 at 3:15 PM, Guillaume Laforge <glaforge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> wrote:
>> > What's wrong with lexical scoping?
>> > On the contrary, it seems like a desirable feature.
>> >
>> > On Mon, Oct 13, 2008 at 2:58 PM, Dierk König <dierk.koenig-vS5zOjhOW+wAvxtiuMwx3w@public.gmane.org>
>> > wrote:
>> >> +1
>> >>
>> >> Dierk
>> >>
>> >> P.S. as long as this doesn't mean lexical scoping ;-)
>> >>
>> >> | -----Original Message-----
>> >> | From: Alex Tkachman [mailto:alex.tkachman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
>> >> | Sent: Montag, 13. Oktober 2008 14:16
>> >> | To: dev <at> groovy.codehaus.org
>> >> | Subject: [groovy-dev] <at> Use ast transformation
>> >> |
>> >> | Any objections for adding <at> Use ast transformation, which
>> >> | applies listed categories to either each method in the class
>> >> | or particular method or constructor
>> >> |
>> >> | <at> Use(CategoryForClass_1, CategoryForClass_2) class TestClass {
>> >> |
>> >> |     <at> Use(CategoryForMethod)
>> >> |    def method () {
>> >> |         //
>> >> |    }
>> >> | }
>> >> |
>> >> |
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>> >
>>
>>
>>
>> --
>> 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
>>
>>
>
>



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

   http://xircles.codehaus.org/manage_email



Martin C. Martin | 1 Mar 18:38 2009

[groovy-dev] Small optimization of boxing/unboxing?

Hi all,

The java spec suggests using valueOf() instead of "new" where possible:

"If a new Short instance is not required, this method should generally 
be used in preference to the constructor Short(short), as this method is 
likely to yield significantly better space and time performance by 
caching frequently requested values."

We use it for boxing ints, but not for any other type.  Perhaps it would 
speed things up a little?

Best,
Martin

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

    http://xircles.codehaus.org/manage_email

Guillaume Laforge | 1 Mar 18:47 2009

Re: [groovy-dev] Small optimization of boxing/unboxing?

If you can invent some benchmark to test that, and if the results are
worthwhile, we can certain make that optimization.

On Sun, Mar 1, 2009 at 18:38, Martin C. Martin
<martin@...> wrote:
> Hi all,
>
> The java spec suggests using valueOf() instead of "new" where possible:
>
> "If a new Short instance is not required, this method should generally be
> used in preference to the constructor Short(short), as this method is likely
> to yield significantly better space and time performance by caching
> frequently requested values."
>
> We use it for boxing ints, but not for any other type.  Perhaps it would
> speed things up a little?
>
> Best,
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

--

-- 
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

    http://xircles.codehaus.org/manage_email

Alexander Veit | 1 Mar 18:57 2009
Picon
Picon

Re: [groovy-dev] Small optimization of boxing/unboxing?

> Martin C. Martin wrote:
> The java spec suggests using valueOf() instead of "new" where 
> possible:
> 
> "If a new Short instance is not required, this method should 
> generally 
> be used in preference to the constructor Short(short), as 
> this method is 
> likely to yield significantly better space and time performance by 
> caching frequently requested values."
> 
> We use it for boxing ints, but not for any other type.  
> Perhaps it would 
> speed things up a little?

There are already some JIRAs:

http://jira.codehaus.org/browse/GROOVY-2988
http://jira.codehaus.org/browse/GROOVY-1915

Maybe they should be reopened.

--

-- 
Cheers,
Alex

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

    http://xircles.codehaus.org/manage_email

Alex Tkachman | 1 Mar 19:05 2009
Picon

Re: [groovy-dev] Small optimization of boxing/unboxing?

AFAIK it is done already. At least at some places

On Sun, Mar 1, 2009 at 8:38 PM, Martin C. Martin <martin-i949vRgkDusU9HFyfbEPPQC/G2K4zDHf@public.gmane.org> wrote:
Hi all,

The java spec suggests using valueOf() instead of "new" where possible:

"If a new Short instance is not required, this method should generally be used in preference to the constructor Short(short), as this method is likely to yield significantly better space and time performance by caching frequently requested values."

We use it for boxing ints, but not for any other type.  Perhaps it would speed things up a little?

Best,
Martin

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

  http://xircles.codehaus.org/manage_email



Alexander Veit | 1 Mar 19:17 2009
Picon
Picon

Re: [groovy-dev] Small optimization of boxing/unboxing?

> glaforge@... wrote:
> If you can invent some benchmark to test that, and if the results are
> worthwhile, we can certain make that optimization.

IMO the Java documentation justifies to replace new with valueOf() for
classes that provide this method.

Benchmarking is difficult. E.g. Char.valueOf(char) is at least ten times
faster than new Char(char). But the main improvement is probably reduced
garbage creation.

--

-- 
Cheers,
Alex

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

    http://xircles.codehaus.org/manage_email

Jim White | 1 Mar 21:05 2009

Re: [groovy-dev] Small optimization of boxing/unboxing?

Martin C. Martin wrote:

> Hi all,
> 
> The java spec suggests using valueOf() instead of "new" where possible:
> 
> "If a new Short instance is not required, this method should generally 
> be used in preference to the constructor Short(short), as this method is 
> likely to yield significantly better space and time performance by 
> caching frequently requested values."
> 
> We use it for boxing ints, but not for any other type.  Perhaps it would 
> speed things up a little?

DGM does that everywhere possible in Groovy 1.6+.  I didn't look to find 
where else boxed primitives are needed.  Feel free to point them 
out/submit a patch.

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

This change can't be made for Groovy 1.5 because it supports JDK 1.4. 
Groovy 1.6 allows us to use JDK 1.5 methods on JDK 1.4 via retrotranslation.

Jim

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

    http://xircles.codehaus.org/manage_email


Gmane