I think we need a stronger argument for a switch than "I might shoot myself in the foot". :-)
It's pretty simple to force methods to be called (write them) and to avoid fields from being loaded in odd cases (don't include them in the select clause). Let's give it some time the way it is, and if many people start finding unexpected results due to field mappings, then let's add a switch at that time. Cheers, Clinton On 2/10/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
How can I argue with that advice? :-) However, I am a man of many errors and I will not be able to use unit tests to find these problems anymore unless there is a way for iBatis to tell me I forgot my methods. I really really don't want direct-field access to bite my designs. It might just be too easy for bugs to get by unless the tool is smarter. Paul Clinton Begin wrote: > So far, there's no switch to turn it on or off. > > I guess I'm thinking if you want to enforce that it go through > methods, then write the methods. :-) > > Clinton > > On 2/10/07, Paul Benedict <[EMAIL PROTECTED]> wrote: >> Clinton, >> >> That's awesome! Good job! >> >> May I ask if this field-setter access is something I need to turn on or >> off? I hope so. I want to enforce my usage to go through methods. >> >> Paul >> >> Clinton Begin wrote: >> > Okay... >> > >> > I've made the change. It now uses fields only if a get or set method >> > doesn't exist. Of course, the decision is independent for get and >> > set, so if a set doesn't exist, but a get does, it will use the field >> > for setting, but the getter for getting. I've also enabled private >> > constructor access. >> > >> > Basically this means, iBATIS now works with POJOs for real... we don't >> > depend on the JavaBeans spec at all really. You can use your own >> > property syntax and private default constructors with parameterized >> > constructors for programmatic construction. >> > >> > Pretty cool stuff really. >> > >> > Cheers, >> > Clinton >> > >> > On 2/10/07, Clinton Begin <[EMAIL PROTECTED]> wrote: >> >> > If you >> >> > have getters/setters then we'll use them. If not, then we'll use >> >> the fields >> >> > directly. End of story. >> >> >> >> This is my preference now. >> >> >> >> The person that asked me about field mappings that originally got me >> >> to work on it last week is of the mind that we should just keep it >> >> simple like this. Since that was your gut feeling as well as Paul's, >> >> I think we should run with it. >> >> >> >> I think we're over-thinking the solution now. Let us come down from >> >> our ivory tower. :-) >> >> >> >> Clinton >> >> >> >> On 2/10/07, Jeff Butler <[EMAIL PROTECTED]> wrote: >> >> > Is there any realistic non-academic use case for bypassing the >> >> > getters/setters if they exist? In other words, if you want to >> go by >> >> plane >> >> > then don't rent a car :) >> >> > >> >> > We really encourage people to keep their POJOs simple. I'd sure >> >> hate to see >> >> > us encourage wierd or overly complex design just because we can. >> >> Maybe we >> >> > should bypass all the non-standard syntax and configuration >> >> options. If you >> >> > have getters/setters then we'll use them. If not, then we'll use >> >> the fields >> >> > directly. End of story. >> >> > >> >> > Jeff Butler >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On 2/10/07, Paul Benedict <[EMAIL PROTECTED]> wrote: >> >> > > OGNL uses property notation syntax which calls getters and >> >> setters. As >> >> > > for the parenthesis syntax, there is no precedent in the market >> >> for such >> >> > > a syntax being used to access fields directly. The syntax should >> >> be the >> >> > > same (I want to navigate to X), with an additional attribute >> >> specifying >> >> > > how it should be done (take me by plane or car). >> >> > > >> >> > > Paul >> >> > > >> >> > > >> >> > > >> >> > >> >> >> > >> >
