Isn't that what constructors are for? On 2/11/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
Absolutely not. :-) Direct field mapping for the purposes of immutable classes or non-bean types would be pointless. So yes, we're completely ignoring private on fields, setters, and constructors. I don't see a problem with it...it's how it's done. We won't break getter/setter encapsulation, because if the methods exists, we use them. Believe it or not, doing this allows people to build safer applications. JavaBeans are the real threat to encapsulation. They force us to have public mutators and a default constructor, both of which can result in a class ending up in an inconsistent state. So yes. Our framework (like many) ignores access modifiers so that programmers can actually USE access modifiers effectively. How ironic. ;-) Clinton On 2/10/07, Brandon Goodin <[EMAIL PROTECTED]> wrote: > Just curious. Are we still honoring access privileges on fields or are we > doing an end around on them and setting regardless? I'm hoping we still > honor public, package, protected, private. Otherwise that can get > unpredictable. > > Brandon > > On 2/10/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > > Very well. In fact, the fallback to fields may turn out to be > > advantageous. Let's see how it goes, as you said, and listen to the > > feedback. Thanks Clinton! > > > > Clinton Begin wrote: > > > 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 > > > >
