can BigDecimal be available by default

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

can BigDecimal be available by default

Scott Hickey-3
The discussion about @Property got me thinking about something more annoying to me than @Property.

It seems strange that BigDecimal is the default decimal data type but I have to explicitly import it in my GroovyBeans. It's the only "basic" data type that I explicitly import.

BigDecimal is great default for decimal numbers. I personally can't think of a business situation where there is a decimal point in a number that I haven't cared about its accuracy in a math equation. If it has decimal point, it always been additive in some way.

If BigDecimal is the Groovy default decimal data type, shouldn't it just be there ?

import java.math.BigDecimal   // Why just this one ?
class XyzBean {
    @Property Integer id
    @Property String description
    @Property BigDecimal participationPct
    @Property Date effectiveDate
    @Property Double someDouble
}

Scott


Yahoo! Mail
Use Photomail to share photos without annoying attachments.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: can BigDecimal be available by default

Jochen Theodorou
Scott Hickey schrieb:
[...]
> It seems strange that BigDecimal is the default decimal data type but I
> have to explicitly import it in my GroovyBeans. It's the only "basic"
> data type that I explicitly import.

Know what, I thought the same thing yesterday ;)
So I added BigInteger and BigDecimal as default import a minute ago

bye blackdrag
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: can BigDecimal be available by default

LARSON, BRIAN (SBCSI)-2
In reply to this post by Scott Hickey-3
This information is hard to find on the web site.  I finally found
something at
http://docs.codehaus.org/display/GROOVY/2005/04/06/Groovy+JSR+1+released
; which says the following are automatically imported: java.lang,
java.io, java.net, java.util.  That is what I had in a presentation I
wrote as well.  I think groovy.lang and groovy.util are also imported.

The http://groovy.codehaus.org/Scripts+and+Classes and
http://groovy.codehaus.org/Running pages had lots of wiki format
problems and dead links.  I think I've fixed all these issues and I
documented the automatic importing as well as a few other things like
that variables are not required to be declared in scripts (they are put
into the binding).  I didn't have time to actually test what I
documented, so please review these pages to make sure I didn't lie.

I think we should import all of java.math now as well (not just
BigInteger and BigDecimal).  The package (in 1.5) only includes
BigDecimal, BigInteger, MathContext and RoundingMode.  For now, I
documented it that way on the script and classes page.  If you don't
like it I'll change it.

Brian Larson
AT&T (formerly named SBC)

-----Original Message-----
From: Jochen Theodorou [mailto:[hidden email]]
Sent: Tuesday, March 07, 2006 4:42 PM
To: [hidden email]
Subject: Re: [groovy-dev] can BigDecimal be available by default


Scott Hickey schrieb:
[...]
> It seems strange that BigDecimal is the default decimal data type but
I
> have to explicitly import it in my GroovyBeans. It's the only "basic"
> data type that I explicitly import.

Know what, I thought the same thing yesterday ;)
So I added BigInteger and BigDecimal as default import a minute ago

bye blackdrag
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: can BigDecimal be available by default

Jochen Theodorou
LARSON, BRIAN (SBCSI) schrieb:
[...]
> I think we should import all of java.math now as well (not just
> BigInteger and BigDecimal).  The package (in 1.5) only includes
> BigDecimal, BigInteger, MathContext and RoundingMode.  For now, I
> documented it that way on the script and classes page.  If you don't
> like it I'll change it.

I amde a direct import of these because an import of the math package
means to do much more testing for the existance of classes. If you look
at this Script "a = b". It is simple... but I don't know what b is. It
could be a class, so I have to check java.lang.b, java.util.b,
java.io.b, java.net.b, groovy.lang.b, groovy.util.b. Each of these
lookups ncludes the lookup for a script which means it is time
consuming.. And this is done many, many times. So I am not keen to add a
new package import.

But maybe... maybe we could exclude the default imports if the class
names starts with a small letter... hmm ... I think that would speed up
the compiler a little. I think good enough to add the math package to
the imports.

So if all people agree I will add this optimization and the additional
default import.

bye blackdrag

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: can BigDecimal be available by default

LARSON, BRIAN (SBCSI)-2
In reply to this post by Scott Hickey-3
Sounds good.  You could also explicitly import the 4 classes
(RoundingMode is an enum) which would accomplish the same result without
any significant performance penalty.  Of course, you would have to keep
up with new classes added to this package in the JDK, but that would be
infrequent (JDK 1.6 doesn't seem to add any).  I suppose this might also
make the code a little JDK-specific, but I think it should fail with
older JDKs in a predictable way.

Brian Larson
AT&T

-----Original Message-----
From: Jochen Theodorou [mailto:[hidden email]]
Sent: Sunday, March 12, 2006 5:42 AM
To: [hidden email]
Subject: Re: [groovy-dev] can BigDecimal be available by default


LARSON, BRIAN (SBCSI) schrieb:
[...]
> I think we should import all of java.math now as well (not just
> BigInteger and BigDecimal).  The package (in 1.5) only includes
> BigDecimal, BigInteger, MathContext and RoundingMode.  For now, I
> documented it that way on the script and classes page.  If you don't
> like it I'll change it.

I amde a direct import of these because an import of the math package
means to do much more testing for the existance of classes. If you look
at this Script "a = b". It is simple... but I don't know what b is. It
could be a class, so I have to check java.lang.b, java.util.b,
java.io.b, java.net.b, groovy.lang.b, groovy.util.b. Each of these
lookups ncludes the lookup for a script which means it is time
consuming.. And this is done many, many times. So I am not keen to add a

new package import.

But maybe... maybe we could exclude the default imports if the class
names starts with a small letter... hmm ... I think that would speed up
the compiler a little. I think good enough to add the math package to
the imports.

So if all people agree I will add this optimization and the additional
default import.

bye blackdrag

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: can BigDecimal be available by default

Scott Hickey-3
Am I understanding correctly that the intent would be to explicitly import BigDecimal in a.groovy but not A.groovy ?

"LARSON, BRIAN (SBCSI)" <[hidden email]> wrote:
Sounds good. You could also explicitly import the 4 classes
(RoundingMode is an enum) which would accomplish the same result without
any significant performance penalty. Of course, you would have to keep
up with new classes added to this package in the JDK, but that would be
infrequent (JDK 1.6 doesn't seem to add any). I suppose this might also
make the code a little JDK-specific, but I think it should fail with
older JDKs in a predictable way.

Brian Larson
AT&T

-----Original Message-----
From: Jochen Theodorou [mailto:[hidden email]]
Sent: Sunday, March 12, 2006 5:42 AM
To: [hidden email]
Subject: Re: [groovy-dev] can BigDecimal be available by default


LARSON, BRIAN (SBCSI) schrieb:
[...]
> I think we should import all of java.math now as well (not just
> BigInteger and BigDecimal). The package (in 1.5) only includes
> BigDecimal, BigInteger, MathContext and RoundingMode. For now, I
> documented it that way on the script and classes page. If you don't
> like it I'll change it.

I amde a direct import of these because an import of the math package
means to do much more testing for the existance of classes. If you look
at this Script "a = b". It is simple... but I don't know what b is. It
could be a class, so I have to check java.lang.b, java.util.b,
java.io.b, java.net.b, groovy.lang.b, groovy.util.b. Each of these
lookups ncludes the lookup for a script which means it is time
consuming.. And this is done many, many times. So I am not keen to add a

new package import.

But maybe... maybe we could exclude the default imports if the class
names starts with a small letter... hmm ... I think that would speed up
the compiler a little. I think good enough to add the math package to
the imports.

So if all people agree I will add this optimization and the additional
default import.

bye blackdrag



Yahoo! Mail
Use Photomail to share photos without annoying attachments.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: can BigDecimal be available by default

Jochen Theodorou
Scott Hickey schrieb:
> Am I understanding correctly that the intent would be
> to explicitly import BigDecimal in a.groovy but not A.groovy ?

no my optimizations was to not look for "a" in the package java.lang,
java.util, java.not, java.math, groovy.lang, groovy.util. Whereas any
String to be resolved as class will be looked up there too.

bye blackdrag

Loading...