Does anyone have any info to share on the differences between using extended class dot notation versus methods, when manipulating a notes document? That is, apart from the obvious (methods can return a value, and are needed to set an item class, for example, and that appenditem can be ‘evil’ if you are not careful).
I read recently that using dot notation was slower and not as efficient, and the author suggested that using dot notation was ‘lazy.’ I generally respect this author, so it came as a surprise.
Performance aside, it seems to me that dot notation is far more sensible for setting values than the various methods.
Anyone?
Subject: Dot notation versus Methods (NotesDocument)
Using methods (GetItemValue, ReplaceItemValue) is unambiguous – it is obvious both to the compiler and to any maintenance programmer that you are setting/getting the value of an item rather than an intrinsic property of a NotesDocument. There are more than a few of us who ran into ambiguity problems when the Lock property was added to the NotesDocument class in Notes and Domino 6 – compiled code would, of course, continue to work, but if the code was ever edited (and that included editing a form that accessed an item named Lock in its event code) would cause errors.
Readable, unambiguous, works properly with type-ahead both in Designer and in outside IDEs – my vote goes to explicit method calls as a best practice.
Subject: Dot notation versus Methods (NotesDocument)
There is nothing inherently wrong with extended dot notation, but I should warn you that this is a bit of a religious battle, meaning there are people greatly opposed and people greatly in favor, and they have trouble listening to rational arguments on either side. This is not mean to object to Stan Rogers, who is one of the great contributors to this forum, but just to point out that you will hear heated opinions, but relatively few solid reasons for either position. There is no measurable performance difference. Some object, rightly, to the idea that you can cause a problem between one version and the next if an item name is turned into a keyword. Others object, rightly, that the longer notation is somewhat harder to read. Others object, rightly, that the engine has a bit harder time distinguishing a spelling error in a method from an item (e.g., doc.GetFristItem could be an item named GetFristItem or a spelling error meaning GetFirstItem).
There are plenty of arguments on both sides. Mostly, don’t feel that you are doing something bad no matter which you choose. You are simply doing whichever you do.