Re: svn commit: r814145 - in /ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting: finaccount/FinAccountPaymentServices.java invoice/InvoiceServices.java

[Adam Heath-2]

[hidden email] wrote:
> Author: lektran
> Date: Sat Sep 12 11:20:30 2009
> New Revision: 814145
>
> URL: http://svn.apache.org/viewvc?rev=814145&view=rev
> Log:
> Fix some compilations errors I introduced, UtilMisc.toMap is nowhere near as much fun as it used to be

That's because it's safer.

[Scott Gray-2]

Well I'm glad we've managed to solve a problem that has caused us so  
many issues in the past.

Regards
Scott

On 16/09/2009, at 9:48 AM, Adam Heath wrote:

> [hidden email] wrote:
>> Author: lektran
>> Date: Sat Sep 12 11:20:30 2009
>> New Revision: 814145
>>
>> URL: http://svn.apache.org/viewvc?rev=814145&view=rev
>> Log:
>> Fix some compilations errors I introduced, UtilMisc.toMap is  
>> nowhere near as much fun as it used to be
>
> That's because it's safer.

[Adam Heath-2]

Scott Gray wrote:
> Well I'm glad we've managed to solve a problem that has caused us so
> many issues in the past.

It's not just about solving problems.  It's also about documentation.

I've thought about extending the service engine, so that parameter
definitions can have generics markup.  Initially, the extra markup
would just be thrown away(this is how groovy deals with generics).

[Scott Gray-2]

Big +1 on the service definition enhancement, I cringe whenever I see  
an undocumented List or Map as an attribute because I have to go  
digging to find out what it is.

In general I like generics and I've been adding it whenever I have  
time.  My main complaint about UtilMisc is that a decent portion of  
the usefulness has disappeared, for example I want to create a list of  
EntityConditions:
List<EntityCondition> condList =  
UtilMisc.toList(EntityCondition.makeConditionDate("fromDate",  
"thruDate"));  //  Not allowed even though EntityDateFilterCondition  
extends EntityCondition
condList.add(someOtherCondition);

or this common map usage:
Map<String, Object> serviceMap = UtilMisc.toMap("param1",  
"aString");  // Eclipse doesn't complain but results in a compile time  
error
serviceMap.put("param2", aBigDecimal);

I just don't like having to force it to use my types by repeating  
myself with another set of <...>.  It gets to the point where it's  
easier to use the javolution collections and have the extra  
newInstance line.

Regards
Scott

On 17/09/2009, at 3:25 AM, Adam Heath wrote:

> Scott Gray wrote:
>> Well I'm glad we've managed to solve a problem that has caused us so
>> many issues in the past.
>
> It's not just about solving problems.  It's also about documentation.
>
> I've thought about extending the service engine, so that parameter
> definitions can have generics markup.  Initially, the extra markup
> would just be thrown away(this is how groovy deals with generics).
>