David E Jones wrote:
>
> On Oct 15, 2007, at 4:48 PM, Adam Heath wrote:
>
>> David E Jones wrote:
>>>
>>> Adam,
>>>
>>> It's pretty clear you like this idea and don't want to back down, so I'm
>>> not going to push back.
>>
>> It's been a problem for me(and Ean, my coworker) since we started using
>> OfBiz. It's not something new. It's made our job *more* difficult.
>
> Could you be more specific? What has made your job more difficult?
MyEvent.groovy:
== What I currently do:
def value = delegator.findByPrimaryKeyCache("EntityName", [fieldName:
"fieldValue"])
if ("Y".equals(value.booleanField)) {
// default false logic
==
== What I'd like to do:
if (value.booleanField) {
// default false logic
==
Groovy treats maps as objects with properties, and can automatically
pull out fields. It also does automatic boxing/unboxing, including
handling nulls(so that sql trinary logic works as expected).
Additionally, Boolean.TRUE.equals(value.get("booleanField")) is easier
to understand, than "Y".equals(value.get("booleanField")). In the
latter case, which scanning the code, it's hard to know if booleanField
is really a boolean-typed field, or a single-character string field.
I'd have to look at the entity definition to be sure.
So, there's a valid concern. Seeing a compare to a "Y" or an "N", could
mean it's a single-character field, a string field, *or* a boolean
field. It's not known by looking at just the code in question. Whereas
if it was a boolean compare, there would be no doubt.
Additionally, as mentioned before, new users seeing ofbiz for the first
time are used to dealing with their language's native objects. This Y/N
pattern is not really a boolean, but an attempt to graft something new
into the programming system. It's more to learn.
