headers
Miles Parker | 1 Apr 2004 01:14
Picon
Favicon

Re: Groovy Performance / Compiling to static bytecode

LARSON, BRIAN (SBCSI) wrote:

>>There's still heaps more work we can do to improve performance. e.g. 
>>we've not yet implemented static method dispatch when 
>>static-typing is 
>>used.

I'll bet, and assume that getting the basic mechanics working is 
higher-priority. Understand we're < 1.0 here -- at this point I'm most concerned 
w/ long-term prospects.

> We've done some things recently to improve performance in specific
> situations.
> There is much more that can be done.  I looked into this area recently
> and 
> I think it is possible to do more in situations where the compiler can
> determine what to call directly from byte code (e.g. as James said, 
> static typed method calls).

Yea, that's the idea. And that the groovy compiler could (at the cost of losing 
dynamic behavior) infer the static type at compile-time in order to lock-down 
everything possible on the groovy side. Perhaps a compiler switch for getting a 
static version of your groovy code. (As everything on  the Java side is allready 
locked down, it seems to me that the interfacing with the Java side part of this 
would be quite 'easy'.)

Apologise if this has already been discussed or if I've missed something 
obvious, but as an aside, one possibility would be to provide a programming 
construct to define static methods. (Not <i>static</i>, though! :-) Talk about 
your confusing keywords..) Apple's Dylan language used to have such a thing.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Chris Poirier | 1 Apr 2004 10:43

Changes to the Groovy parser/lexer

Hi all,

As promised, here is the list of changes recently made to Groovy.

1) Untyped integer declarations will use the smallest of BigInteger,
Long, or Integer that is applicable.  To force a size, you can append G,
L, or I, respectively, upper or lower case, to any base 10 integer.
Hex and octal notations are also now supported.

2) Untyped decimal declarations will now use BigDecimal.  To force
another scale, you can append G, D, of F (upper or lower case), to get
BigDecimal, Double, or Float, respectively.  (Thanks goes to Brian
Larson for a lot of this code.)  You can now supply an exponent on a
decimal number as follows: 10.392e3 (which equals 10392). The type
specifier follows the exponent, if present.

3) GString expressions can now contain /any/ valid Groovy expression,
including closures and other GStrings.  No additional quoting is
required for the data between the ${}.  The escape character for ${} has
changed to \ from $.

4) Closures parameters are now to be enclosed in two pipe symbols (or
none, in the anonymous case).  The single-pipe-after-the-list is
deprecated and will be removed from the code in the next release.  Valid
syntax:
   c = { |x, y, z| doStuff( ... ) }
   c = { doStuff( ... ) }

For now, make sure you leave a space between the two pipes if there are
no parameters.  It's necessary because of a bug that has yet to be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Dwelly | 1 Apr 2004 10:37

Re: Mike on Properties

I'm still learning groovy so I read the entry with some interest, and his 
other comments on groovy with a slight sense of alarm. Whitespaces and 
newlines are meaningful in some contexts ? It could cause problems round 
here because despite our best efforts at standardizing code style between 
the various people who work and have worked on our projects - differences 
in layout do creep in. I wonder if there's a potential set of nasty 
gotcha's waiting for us if we attempt team programming with groovy (someone 
please, reassure me).

Regarding optionality of ; If dropping that simplified the parser, I 
certainly wouldn't be disturbed by the requirement. I've been using Pascal, 
C, C++, and Java for so long, its all I can do to stop myself typing a ; at 
the end of an English sentence let alone a groovy one;

Regarding the :rw suggestion, I dunno. I haven't used groovy enough to 
understand the impact. But it immediately struck me that it leads fairly 
naturally to :x which presumably has something to do with closures.

Andy
Permalink | Reply | 1 comment |
headers
bing ran | 1 Apr 2004 13:09

RE: Changes to the Groovy parser/lexer

Sorry for my previous email. It all works now. It was my Eclipse CVS
quirk. 

-br
Permalink | Reply | 0 comments |
headers
jastrachan | 1 Apr 2004 14:09
Picon

Re: Mike on Properties


On 1 Apr 2004, at 09:37, Andy Dwelly wrote:

> I'm still learning groovy so I read the entry with some interest, and 
> his other comments on groovy with a slight sense of alarm. Whitespaces 
> and newlines are meaningful in some contexts ?

Thats pretty much been fixed now in the new parser.

>  It could cause problems round here because despite our best efforts 
> at standardizing code style between the various people who work and 
> have worked on our projects - differences in layout do creep in. I 
> wonder if there's a potential set of nasty gotcha's waiting for us if 
> we attempt team programming with groovy (someone please, reassure me).

Please be assured that the JSR will remove as much of the confusing & 
ambiguous parts of the language as possible.

> Regarding optionality of ; If dropping that simplified the parser, I 
> certainly wouldn't be disturbed by the requirement. I've been using 
> Pascal, C, C++, and Java for so long, its all I can do to stop myself 
> typing a ; at the end of an English sentence let alone a groovy one;

I hear you - its up to the JSR to decide that one but FWIW languages 
like JavaScript and Ruby (to name just 2) do quite fine without 
mandatory ;

> Regarding the :rw suggestion, I dunno. I haven't used groovy enough to 
> understand the impact. But it immediately struck me that it leads 
> fairly naturally to :x which presumably has something to do with
(Continue reading)

Permalink | Reply | 0 comments |
headers
jastrachan | 1 Apr 2004 14:27
Picon

Java Beans support (was Re: Mike on Properties)

On 31 Mar 2004, at 23:54, Cedric Beust wrote:
>  Well, thanks Mike for finally delivering.
>
>  I posted a few comments on your analysis in my weblog, but at this 
> point, I think we should take the discussion on this list.  It looks 
> like the JSR EG has their work cut out for them :-)

:)

Agreed. Thanks to both of you for this - especially all the work that 
went into Mikes analysis.

There are various different issues that Mikes review covered. To ease 
the discussion I'm gonna try keep things in threads.

One was the newline sensitivity issue - which I think is now fixed in 
CVS and if it is not now fixed its a bug that we should fix. We can 
discuss that at length in another thread if need be. Another issue 
covered in passing was autoboxing support (that numbers are treated as 
objects) which again we can split off into another thread if need be.

But mostly the analysis covered beans & properties.
Its important to make the clear distinction between the Groovy support 
for working with existing Java Beans and having syntax sugar in Groovy 
to define new Java Beans.

For me quite a bit of of Mike's criticisms are actually criticisms of 
the Java Beans specification and the Java Beans support thats been in 
the JDK since about 1.1. IIRC.
(Continue reading)

Permalink | Reply | 0 comments |
headers
jastrachan | 1 Apr 2004 14:35
Picon

Re: Mike on Properties

On 31 Mar 2004, at 23:54, Cedric Beust wrote:
>  Well, thanks Mike for finally delivering.
>
>  I posted a few comments on your analysis in my weblog, but at this 
> point, I think we should take the discussion on this list.  It looks 
> like the JSR EG has their work cut out for them :-)

I just thought I'd answer Mike's conclusions one by one...

	1.  	Groovy properties aren't about fields. They're about what get and 
set methods you have. The bonus case demonstrates that you can have a 
Groovy property with no field at all.

Agreed. Groovy properties are about Java Beans properties.

	2.  	Public fields in Groovy result in private fields in Java. Private 
fields in Groovy result in private fields in Java.

Agreed. You could argue that this is implementation details

	3.  	Auto-generation of get/set methods only occurs for public fields. 
For private fields, you're on your own

Agreed - though why would you use a getter/setter method on a private 
field?

	4.  	Newline sensitivity sucks :-(

Agreed and has been fixed AFAIK
(Continue reading)

Permalink | Reply | 2 comments |
headers
Clint Combs | 1 Apr 2004 14:48
Favicon
Gravatar

RE: Heads up - new way of doing Groovy Markup

John,

Thanks for the explanation.  That's much clearer now.

Do you know if the markup changes you've made will be included in a new beta
release soon?  (I'm using beta-4)  If not, I'll grab the source from CVS and
do my first Groovy build!

-Clint

-----Original Message-----
From: groovy-user-admin@...
[mailto:groovy-user-admin@...] On Behalf Of John Wilson
Sent: Wednesday, March 24, 2004 11:02 AM
To: groovy-user@...
Subject: Re: [groovy-user] Heads up - new way of doing Groovy Markup

On 24 Mar 2004, at 15:03, clint@... wrote:

> John,
>
> I'm looking at the Writable interface.  Can you give me a brief 
> explanation
> about how Writable figures into the picture?  It sounds like you're 
> saying
> that the objects being created implement this interface... ?
>

Clint,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Anthony Eden | 1 Apr 2004 17:52

Groovy .Net Port: Noovy

I've posted a weblog entry ( http://weblog.anthonyeden.com/ ) about my 
Groovy .Net port, called Noovy.

Sincerely,
Anthony Eden
Permalink | Reply | 2 comments |
headers
Max Kington | 1 Apr 2004 15:15

RE: Groovy .Net Port: Noovy

Couple more 'o's in the middle of the name and it'll be cool

-----Original Message-----
From: groovy-user-admin@...
[mailto:groovy-user-admin@...]On Behalf Of
Anthony Eden
Sent: 01 April 2004 16:53
To: groovy-user@...
Subject: [groovy-user] Groovy .Net Port: Noovy

I've posted a weblog entry ( http://weblog.anthonyeden.com/ ) about my 
Groovy .Net port, called Noovy.

Sincerely,
Anthony Eden
_______________________________________________
groovy-user mailing list
groovy-user@...
http://lists.codehaus.org/mailman/listinfo/groovy-user
Permalink | Reply | 1 comment |

Gmane