okay
On 2/11/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
Yes, you're absolutely right about that. Constructor injection is our
goal going forward. It's quite a bit harder to implement than direct
field mapping, but I would like to see it. I may look into it next
week.
Direct field is still
Yes, you're absolutely right about that. Constructor injection is our
goal going forward. It's quite a bit harder to implement than direct
field mapping, but I would like to see it. I may look into it next
week.
Direct field is still important though, for people that don't buy into
constructor
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 do
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, be
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 w
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 t
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 i
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 t
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 someth
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
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 ac
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. Sinc
Ah, non-academic use case... I don't mean to start a flame war, but
"Hibernate has it!" :-) There's probably a good chance a user of
Hibernate may have recommended this feature. And the purpose is to allow
properties to be set without having to expose getters.
I am strongly against allowing th
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
rce
iBATIS to try
> >> accessing
> >> the field first, then the getter if field is not
present. Think this
> >> would
> >> do?
lem will arise with resultMaps that will need this
> > > >> notation at
> > > >> the same time (to know if we call a setter or a use the field).
> > > >>
> > > >> I personally think it is to late to force people to change their
iBATIS
> > >> habit. But make sure that they'll know what the framework will do.
> For
> > >> instance calling the getter if present, if not accessing the field
> > >> directly.
> > >>
> > >> Maybe the notation can be optionnal and
e getter if present, if not accessing the field
> >> directly.
> >>
> >> Maybe the notation can be optionnal and will force iBATIS to try
> >> accessing
> >> the field first, then the getter if field is not present. Think this
> >> would
> &
he getter if field is not present. Think this
>> would
>> do?
>>
>> Christian
>>
>>
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On
>> Behalf Of Paul Benedict
>> Sent: Friday, 09 February 2007 15
nedict
Sent: Friday, 09 February 2007 15:17
To: dev@ibatis.apache.org
Subject: Re: Direct-to-Field mappings now implemented.
Poitras and Clinton,
I agree. The refactoring argument is pretty strong. Property notation is
script-like because the actual means to get to the value (method vs.
direct-field
PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Benedict
Sent: Friday, 09 February 2007 15:17
To: dev@ibatis.apache.org
Subject: Re: Direct-to-Field mappings now implemented.
Poitras and Clinton,
I agree. The refactoring argument is pretty strong. Property notation is
script-like because t
Think this would do?
Christian
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Paul Benedict
Sent: Friday, 09 February 2007 15:17
To: dev@ibatis.apache.org
Subject: Re: Direct-to-Field mappings now implemented.
Poitras and Clinton,
I agree. The ref
Poitras and Clinton,
I agree. The refactoring argument is pretty strong. Property notation is
script-like because the actual means to get to the value (method vs.
direct-field access) is totally secondary to the intention. The developer
just needs to express the path, and the framework should be
2007 14:00
To: dev@ibatis.apache.org
Subject: Re: Direct-to-Field mappings now implemented.
It would be easy to do what you describe (very easy actually). And
performance would not suffer at all.
However, I did it specifically because of JavaBean syntax and naming
conflicts. 99% of JavaBeans are w
Your point is interesting, but wouldn't the () notation break maps
transparency?
-Original Message-
From: Clinton Begin [mailto:[EMAIL PROTECTED]
Sent: Friday, 09 February 2007 14:00
To: dev@ibatis.apache.org
Subject: Re: Direct-to-Field mappings now implemented.
It would be easy
It would be easy to do what you describe (very easy actually). And
performance would not suffer at all.
However, I did it specifically because of JavaBean syntax and naming
conflicts. 99% of JavaBeans are written using something like:
String name;
public String getName();
Hence a naming confl
I agree with Jeff that an alternative syntax is questionable and likely
unnecessary. The syntax for accessing members of an object should be the
same, regardless if the property is an instance variable or method. Rather,
there should be a flag which enables direct property access which will be
use
I think this is a good idea.
However, I wonder if it is necessary to add the extra syntax? Could we be
smart enough to use a getter/setter if one exists, else resort to direct
field access? Then there would be no need for the extra parenthesis syntax.
Jeff Butler
On 2/9/07, Clinton Begin <[
Hi all,
I found a few hours tonight to implement direct-to-field mappings. I
don't have any energy left to explain it fully, but it's simple to
use, so here's the summary.
To implement this, I changed the ClassInfo to accept a new pattern of
"property" access. You can now wrap a field names in
29 matches
Mail list logo
