[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] creating a pointcut for primitive

Just a thought...
 
> Iâd like to be able to avoid having every programmer be responsible
> for determining whether the calculation is financial or not
 
But it might be nice if, when they know it is a financial calculation,
they can say that in the code in a way that's susceptible to modern
refactoring and AOP tools.
 
So instead of using BigDecimal directly, you might consider writing your
own static API, e.g.,
 
  x*y -> Financial.multiply(x, y)
 
Then you can implement it however you want, it's clear what's meant,
and it becomes a join point so you can use AOP to apply or change the policy. 
Outside AOP, one advantage is overloading the method so you can
handle your own conversions (and even write your own int wrappers,
e.g., with units).  And there's virtually no overhead in modern VM's if
you implement with static/final/private methods.
 
If you end up extending a compiler, then you have to decide which
int-multiplies (hard to do) or do them all (which might lead to unintended
consequences).
 
Wes
 
------------Original Message------------
From: "Andrew Elegante" <aelegante@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Date: Thu, Feb-9-2006 8:54 AM
Subject: Re: [aspectj-users] creating a pointcut for primitive

Bruno,

 

Thanks for the response.  I had originally planned to do what you were saying, that is convert x*y -> BigDecimal.multiply(x,y) but my boss thought it would be better to just round it out to 8 decimal places or so to get the necessary precision.  Weâre talking about numbers which are used in financial calculations so itâs very important that they be precise.  It doesnât really matter to me which way we do it but Iâd like to be able to avoid having every programmer be responsible for determining whether the calculation is financial or not and doing the appropriate rounding or BigDecimal operations ergo my wish to use Aspects to make it always happen that way.

 

Iâll look into extending AspectJ that way (Eric pointed me to a compiler I can extend).

 

Thanks,

 

Drew

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users