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

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

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

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

[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

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

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

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

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

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