You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Carlos Pita <ca...@gmail.com> on 2009/08/31 23:17:11 UTC
Property/Field resolution order
Hi all,
I'm porting an application persistence layer from hibernate to ibatis.
The hibernate implementation uses field access, and changing to
property access will be asking for trouble at this point of
development. I know ibatis already fallbacks to field access when
there is no property getter/setter, but I yearn for the inverse
resolution order.
As MetaObject accepts an ObjectWrapper as its object parameter...
if (object instanceof ObjectWrapper) {
this.objectWrapper = (ObjectWrapper) object;
} else if (object instanceof Map) {
this.objectWrapper = new MapWrapper(this, (Map)object);
} else {
this.objectWrapper = new BeanWrapper(this, object);
}
...one solution would be to implement a custom ObjectFactory that
wraps the instances created by DefaultObjectFactory inside an
appropriate custom ObjectWrapper, say FieldObjectWrapper. But as
Reflector assumes the property-then-field precendence,
FieldObjectWrapper would have to be written from scratch, because
MetaObject, MetaClass and Reflector would render useless for my
purposes.
What do you think about adding a global configuration option to set
the field/property resolution order? The change is trivial to
implement (just a few tweaks to Reflector, I think), and will be
backwards compatible if the default order remains property-then-field.
This could be very valuable for developers that prefer to go the other
way around, and at a very low cost for ibatis itself. Also, having
properties as a last resort is handy even if you prefer field access
by default.
Best regards
--
Carlos
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Property/Field resolution order
Posted by Clinton Begin <cl...@gmail.com>.
FWIW: You guys probably already thought of this, but you can short circuit
this by using a field naming convention different from the property naming
convention... like "_field"
Clinton
On Sun, Sep 6, 2009 at 10:36 AM, Brandon Goodin <br...@gmail.com>wrote:
> Forget the JavaBean spec and provide column to method mapping :) Then you
> could intentionally map a column to a "set" method on a class if you wanted.
> Of course you may open a can of worms with that since some people may want
> to pass multiple columns to a method. But, then again, that's not much
> different than the new constructor functionality.
> Just my lame .02
>
> Brandon
>
>
>
> On Sun, Sep 6, 2009 at 8:46 AM, <ca...@gmail.com> wrote:
>
>> I'm all for field access! Or a default field-then-property. I'm also
>> fond of the syntax prop.(field) that you came out with time before in
>> the list, but again reversing the default (prop).field.
>>
>> Best regards
>> --
>> Carlos
>>
>>
>> On Sun, Sep 06, 2009 at 01:23:18AM -0600, Clinton Begin wrote:
>> > I'm almost sad that I ever supported JavaBeans properties... fields
>> would
>> > have been so much better. I wonder if it's too late to make that
>> call...
>> >
>> > Does anyone actually care if iBATIS uses getter/setters instead of
>> fields
>> > directly?
>> >
>> > The only case I can think of is for "calculate on set" type logic in
>> > JavaBeans classes (where it calculates a number of other properties
>> based on
>> > setting one).
>> >
>> > Cheers,
>> > Clinton
>> >
>> > On Mon, Aug 31, 2009 at 3:17 PM, Carlos Pita <carlosjosepita@gmail.com
>> >wrote:
>> >
>> > > Hi all,
>> > >
>> > > I'm porting an application persistence layer from hibernate to ibatis.
>> > > The hibernate implementation uses field access, and changing to
>> > > property access will be asking for trouble at this point of
>> > > development. I know ibatis already fallbacks to field access when
>> > > there is no property getter/setter, but I yearn for the inverse
>> > > resolution order.
>> > >
>> > > As MetaObject accepts an ObjectWrapper as its object parameter...
>> > >
>> > > if (object instanceof ObjectWrapper) {
>> > > this.objectWrapper = (ObjectWrapper) object;
>> > > } else if (object instanceof Map) {
>> > > this.objectWrapper = new MapWrapper(this, (Map)object);
>> > > } else {
>> > > this.objectWrapper = new BeanWrapper(this, object);
>> > > }
>> > >
>> > > ...one solution would be to implement a custom ObjectFactory that
>> > > wraps the instances created by DefaultObjectFactory inside an
>> > > appropriate custom ObjectWrapper, say FieldObjectWrapper. But as
>> > > Reflector assumes the property-then-field precendence,
>> > > FieldObjectWrapper would have to be written from scratch, because
>> > > MetaObject, MetaClass and Reflector would render useless for my
>> > > purposes.
>> > >
>> > > What do you think about adding a global configuration option to set
>> > > the field/property resolution order? The change is trivial to
>> > > implement (just a few tweaks to Reflector, I think), and will be
>> > > backwards compatible if the default order remains property-then-field.
>> > >
>> > > This could be very valuable for developers that prefer to go the other
>> > > way around, and at a very low cost for ibatis itself. Also, having
>> > > properties as a last resort is handy even if you prefer field access
>> > > by default.
>> > >
>> > > Best regards
>> > > --
>> > > Carlos
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> > > For additional commands, e-mail: user-java-help@ibatis.apache.org
>> > >
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>>
>
Re: Property/Field resolution order
Posted by Brandon Goodin <br...@gmail.com>.
Forget the JavaBean spec and provide column to method mapping :) Then you
could intentionally map a column to a "set" method on a class if you wanted.
Of course you may open a can of worms with that since some people may want
to pass multiple columns to a method. But, then again, that's not much
different than the new constructor functionality.
Just my lame .02
Brandon
On Sun, Sep 6, 2009 at 8:46 AM, <ca...@gmail.com> wrote:
> I'm all for field access! Or a default field-then-property. I'm also
> fond of the syntax prop.(field) that you came out with time before in
> the list, but again reversing the default (prop).field.
>
> Best regards
> --
> Carlos
>
>
> On Sun, Sep 06, 2009 at 01:23:18AM -0600, Clinton Begin wrote:
> > I'm almost sad that I ever supported JavaBeans properties... fields
> would
> > have been so much better. I wonder if it's too late to make that call...
> >
> > Does anyone actually care if iBATIS uses getter/setters instead of fields
> > directly?
> >
> > The only case I can think of is for "calculate on set" type logic in
> > JavaBeans classes (where it calculates a number of other properties based
> on
> > setting one).
> >
> > Cheers,
> > Clinton
> >
> > On Mon, Aug 31, 2009 at 3:17 PM, Carlos Pita <carlosjosepita@gmail.com
> >wrote:
> >
> > > Hi all,
> > >
> > > I'm porting an application persistence layer from hibernate to ibatis.
> > > The hibernate implementation uses field access, and changing to
> > > property access will be asking for trouble at this point of
> > > development. I know ibatis already fallbacks to field access when
> > > there is no property getter/setter, but I yearn for the inverse
> > > resolution order.
> > >
> > > As MetaObject accepts an ObjectWrapper as its object parameter...
> > >
> > > if (object instanceof ObjectWrapper) {
> > > this.objectWrapper = (ObjectWrapper) object;
> > > } else if (object instanceof Map) {
> > > this.objectWrapper = new MapWrapper(this, (Map)object);
> > > } else {
> > > this.objectWrapper = new BeanWrapper(this, object);
> > > }
> > >
> > > ...one solution would be to implement a custom ObjectFactory that
> > > wraps the instances created by DefaultObjectFactory inside an
> > > appropriate custom ObjectWrapper, say FieldObjectWrapper. But as
> > > Reflector assumes the property-then-field precendence,
> > > FieldObjectWrapper would have to be written from scratch, because
> > > MetaObject, MetaClass and Reflector would render useless for my
> > > purposes.
> > >
> > > What do you think about adding a global configuration option to set
> > > the field/property resolution order? The change is trivial to
> > > implement (just a few tweaks to Reflector, I think), and will be
> > > backwards compatible if the default order remains property-then-field.
> > >
> > > This could be very valuable for developers that prefer to go the other
> > > way around, and at a very low cost for ibatis itself. Also, having
> > > properties as a last resort is handy even if you prefer field access
> > > by default.
> > >
> > > Best regards
> > > --
> > > Carlos
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> > > For additional commands, e-mail: user-java-help@ibatis.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: Property/Field resolution order
Posted by ca...@gmail.com.
I'm all for field access! Or a default field-then-property. I'm also
fond of the syntax prop.(field) that you came out with time before in
the list, but again reversing the default (prop).field.
Best regards
--
Carlos
On Sun, Sep 06, 2009 at 01:23:18AM -0600, Clinton Begin wrote:
> I'm almost sad that I ever supported JavaBeans properties... fields would
> have been so much better. I wonder if it's too late to make that call...
>
> Does anyone actually care if iBATIS uses getter/setters instead of fields
> directly?
>
> The only case I can think of is for "calculate on set" type logic in
> JavaBeans classes (where it calculates a number of other properties based on
> setting one).
>
> Cheers,
> Clinton
>
> On Mon, Aug 31, 2009 at 3:17 PM, Carlos Pita <ca...@gmail.com>wrote:
>
> > Hi all,
> >
> > I'm porting an application persistence layer from hibernate to ibatis.
> > The hibernate implementation uses field access, and changing to
> > property access will be asking for trouble at this point of
> > development. I know ibatis already fallbacks to field access when
> > there is no property getter/setter, but I yearn for the inverse
> > resolution order.
> >
> > As MetaObject accepts an ObjectWrapper as its object parameter...
> >
> > if (object instanceof ObjectWrapper) {
> > this.objectWrapper = (ObjectWrapper) object;
> > } else if (object instanceof Map) {
> > this.objectWrapper = new MapWrapper(this, (Map)object);
> > } else {
> > this.objectWrapper = new BeanWrapper(this, object);
> > }
> >
> > ...one solution would be to implement a custom ObjectFactory that
> > wraps the instances created by DefaultObjectFactory inside an
> > appropriate custom ObjectWrapper, say FieldObjectWrapper. But as
> > Reflector assumes the property-then-field precendence,
> > FieldObjectWrapper would have to be written from scratch, because
> > MetaObject, MetaClass and Reflector would render useless for my
> > purposes.
> >
> > What do you think about adding a global configuration option to set
> > the field/property resolution order? The change is trivial to
> > implement (just a few tweaks to Reflector, I think), and will be
> > backwards compatible if the default order remains property-then-field.
> >
> > This could be very valuable for developers that prefer to go the other
> > way around, and at a very low cost for ibatis itself. Also, having
> > properties as a last resort is handy even if you prefer field access
> > by default.
> >
> > Best regards
> > --
> > Carlos
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> > For additional commands, e-mail: user-java-help@ibatis.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Property/Field resolution order
Posted by Ken Chau <kc...@g2llc.com>.
I wouldn't mind if this was a configurable resolution order.
-Ken
On Sep 6, 2009, at 12:23 AM, Clinton Begin <cl...@gmail.com>
wrote:
> I'm almost sad that I ever supported JavaBeans properties... fields
> would have been so much better. I wonder if it's too late to make
> that call...
>
> Does anyone actually care if iBATIS uses getter/setters instead of
> fields directly?
>
> The only case I can think of is for "calculate on set" type logic in
> JavaBeans classes (where it calculates a number of other properties
> based on setting one).
>
> Cheers,
> Clinton
>
> On Mon, Aug 31, 2009 at 3:17 PM, Carlos Pita
> <ca...@gmail.com> wrote:
> Hi all,
>
> I'm porting an application persistence layer from hibernate to ibatis.
> The hibernate implementation uses field access, and changing to
> property access will be asking for trouble at this point of
> development. I know ibatis already fallbacks to field access when
> there is no property getter/setter, but I yearn for the inverse
> resolution order.
>
> As MetaObject accepts an ObjectWrapper as its object parameter...
>
> if (object instanceof ObjectWrapper) {
> this.objectWrapper = (ObjectWrapper) object;
> } else if (object instanceof Map) {
> this.objectWrapper = new MapWrapper(this, (Map)object);
> } else {
> this.objectWrapper = new BeanWrapper(this, object);
> }
>
> ...one solution would be to implement a custom ObjectFactory that
> wraps the instances created by DefaultObjectFactory inside an
> appropriate custom ObjectWrapper, say FieldObjectWrapper. But as
> Reflector assumes the property-then-field precendence,
> FieldObjectWrapper would have to be written from scratch, because
> MetaObject, MetaClass and Reflector would render useless for my
> purposes.
>
> What do you think about adding a global configuration option to set
> the field/property resolution order? The change is trivial to
> implement (just a few tweaks to Reflector, I think), and will be
> backwards compatible if the default order remains property-then-field.
>
> This could be very valuable for developers that prefer to go the other
> way around, and at a very low cost for ibatis itself. Also, having
> properties as a last resort is handy even if you prefer field access
> by default.
>
> Best regards
> --
> Carlos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: Property/Field resolution order
Posted by Clinton Begin <cl...@gmail.com>.
I'm almost sad that I ever supported JavaBeans properties... fields would
have been so much better. I wonder if it's too late to make that call...
Does anyone actually care if iBATIS uses getter/setters instead of fields
directly?
The only case I can think of is for "calculate on set" type logic in
JavaBeans classes (where it calculates a number of other properties based on
setting one).
Cheers,
Clinton
On Mon, Aug 31, 2009 at 3:17 PM, Carlos Pita <ca...@gmail.com>wrote:
> Hi all,
>
> I'm porting an application persistence layer from hibernate to ibatis.
> The hibernate implementation uses field access, and changing to
> property access will be asking for trouble at this point of
> development. I know ibatis already fallbacks to field access when
> there is no property getter/setter, but I yearn for the inverse
> resolution order.
>
> As MetaObject accepts an ObjectWrapper as its object parameter...
>
> if (object instanceof ObjectWrapper) {
> this.objectWrapper = (ObjectWrapper) object;
> } else if (object instanceof Map) {
> this.objectWrapper = new MapWrapper(this, (Map)object);
> } else {
> this.objectWrapper = new BeanWrapper(this, object);
> }
>
> ...one solution would be to implement a custom ObjectFactory that
> wraps the instances created by DefaultObjectFactory inside an
> appropriate custom ObjectWrapper, say FieldObjectWrapper. But as
> Reflector assumes the property-then-field precendence,
> FieldObjectWrapper would have to be written from scratch, because
> MetaObject, MetaClass and Reflector would render useless for my
> purposes.
>
> What do you think about adding a global configuration option to set
> the field/property resolution order? The change is trivial to
> implement (just a few tweaks to Reflector, I think), and will be
> backwards compatible if the default order remains property-then-field.
>
> This could be very valuable for developers that prefer to go the other
> way around, and at a very low cost for ibatis itself. Also, having
> properties as a last resort is handy even if you prefer field access
> by default.
>
> Best regards
> --
> Carlos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>