ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject RE: Can anyone offer help on "There is no WRITEABLE property named 'lName'"
Date Sat, 18 Aug 2007 16:32:43 GMT
I could make classinfo case insensitive with only a few line changes.  :-)
I guess we wouldn't be breaking compatibility for anyone except the one
person on earth who has both a getXMLText() and getXmlText().  But that
person should be terminated anyway.  ;-)

Cheers,
Clinton

-----Original Message-----
From: larry.meadors@gmail.com [mailto:larry.meadors@gmail.com] On Behalf Of
Larry Meadors
Sent: August-18-07 7:41 AM
To: user-java@ibatis.apache.org
Subject: Re: Can anyone offer help on "There is no WRITEABLE property named
'lName'"

On 8/17/07, Clinton Begin <clinton.begin@gmail.com> wrote:
> <rant>
> God forbid they just leave the damn capitalization as it is typed in the
> first place.  Would TitleCase properties have killed us all?
> </rant>

I'll take the rant a step further. :-)

Why do we need the stupid methods in the first place? The whole idea
of making getStupid/setStupid methods to define properties is utterly
retarded.

In 1995, M$ had a language that defined properties the same way C#
does now. It's not really a novel idea to make them fields with an
option to wrap access to the fields using get/set methods.

Why Sun didn't do this is beyond me.

What they managed to do instead was create a specification that forces
developers to create non-transparent fields - instead of making a
statement like "bean.prop = 5;" we have to do "bean.setProp(5);".

Any OOP zealot will tell you that this breaks one of the first 3 rules
of OOP (encapsulation) because you have to know the implementation -
is it a property, or just a field?

So, here we are 12 years later, and we *still* have to do this. Why?!?

There is *no* reason to keep the spec the same - it could easily be
extended to allow for declarative properties using annotations, or
even simpler (for us) by changing the VM to look for get/set methods
before changing field values directly.

> Does anyone think iBATIS 3 should be completely case insensitive in this
> regard?  Really, do you ever have a need to differentiate two properties
> only by case?

I think that's a fine idea...in fact, I think I have a BeanUtils like
class that does that now somewhere...

Larry


Mime
View raw message