A couple of people responded to my performance tips paper with the suggestion that GetItemValue and ReplaceItemValue should be used in preference to just doc.fieldname.
I agree with the idea (though not enough to always do it myself!), but my testing suggests that performance is not the main reason to do it. I did a little test assigning a value to a field many times using the two different techniques. I found that ReplaceItemValue is a little faster -- 0.0000563 seconds versus 0.0000585 seconds. Not really enough difference to get excited about. Certainly, it's a very small amount of time compared to how long it takes to open a note.
The real reason for using GetItemValue and ReplaceItemValue, in my opinion, is to avoid maintenance problems with your code if IBM adds a new property or method that happens to have the same name as your field. Many people with fields named Lock had this problem when the Lock method was introduced, the next time they tried to edit their old code.
I don't really see the motivation for the extra typing in cases where your fieldname is so unique that the odds of a problem are vanishingly small, or so common that we would be silly to give a new thing the same name (e.g. I think we can be pretty sure there will not be a new property named Form, because it would break so many apps).
- Andre Guirard
Few more reasons :
1) You can pass in variables / constants for your field names. In other words, you can compute a field name based on a scenario in your code, and use that in the statement—you can’t do that with dot notation
2) If you make a habit of using constants / variables for field names, you avoid silly typos causing strange errors in your code: assuming you have Option Declare enabled, you will catch any errors in your field name references at compile time
3) Get/ReplaceItemValue makes it more readable to. You don't need to think "is this an actual form property or is it a field".
4) you can call doc.ReplaceItemValue( "fld", "val" ).IsReaders = True or set another item property.
5) There is definetly a performance penalty in using the dot notation which is invisible if you access 10 items but may have it's importance if you have an agent accessing 1000 items running 10 times currently from the web.