Yes it would. It's transparency vs. expressiveness and control.
I guess it would make it harder to refactor (i.e. encapsulate) a field to a setter method later. Hmmm....I'm slowly being won over. Keep going and you'll have me. ;-) Does anyone like the (brackets)? If I'm the only one, I'll ditch them. Clinton On 2/9/07, Poitras Christian <[EMAIL PROTECTED]> wrote:
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 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 conflict between the field "name" and the property "name". The .NET version does exactly what you describe, and to be honest, I did not like it at all. It was very unintuitive and it had me guessing which it would use. Also, one of my early design mistakes (IMHO) was making maps transparent by using the same .dot notation as JavaBeans properties. I feel it was a mistake to do so. iBATIS has a good history of being predictable because it avoids guessing and magic. When I read a SQL Map, I know exactly what it's going to do and where my data is going to go (with the exception of the hashmap issue). To ensure that it stays that way, I personally think being explicit here is the best route. Can anyone else support the points made by Paul and Jeff? Thoughts? Clinton On 2/9/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > 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 used if no property method exists. If > you're concerned about performance, the probe should record the "best > route" so that this check isn't done every time. > > I recommend a new configuration setting be allowed in the global > configuration and (for overriding) on the resultMap: > > <resultMap ... directFieldAccessFallback="true"> > <property col="street" name= "account.address.street"> </resultMap> > > Paul > > > On 2/9/07, Jeff Butler < [EMAIL PROTECTED]> wrote: > > > > 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 <[EMAIL PROTECTED] > wrote: > > > 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 round > > > brackets to distinguish them from properties. So: > > > > > > "id" is a property. > > > "(id)" is a field. > > > > > > These can be mixed with properties like: > > > > > > "account.(address).street" > > > > > > This last point is important and is the primary reason I didn't > > > use a new XML tag -- that would have severely limited the > > > mix-n-match ability of the feature (and it would have been harder to implement). > > > > > > This approach works for reads and writes and for both inline or > > > external parameter maps and result maps. > > > > > > It should be ubiquitous. Anywhere you used to use property names, > > > you can now use (field) names too. > > > > > > Thoughts? It's not too late to change the syntax (round brackets) > > > or anything else. > > > > > > I think it's the simplest, most flexible and performant approach. > > > > > > Cheers, > > > Clinton > > > > > > > > >
