Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

Please help us prioritize our development efforts in the language team by commenting on the relative priority of these items. Which do you see as most important? Which will actually affect the way you develop applications and if fixed, open up new opportunities to do things you couldn't do before? Which do you see as deployment blocking or affecting your ability to sell your products (and by extension, ours)? This is a multiple choice/ranking question, not essay, so you can just say "JCGH" or some such to indicate your faves. If you feel there is an essay in you waiting to get out, though, go ahead and add that after your ranking. Good ones will get passed on to the development manager along with the summary of results.

A.        If you make a call to a C function and pass it "" for an argument that the C code writes a return value in, the C code overwrites part of the constant memory, so that when you use the constant "" thereafter in LotusScript code (even in other scripts), you will instead get the last return value from the C function. You must bounce Notes or Domino to cure the problem.

B.        A way to cause an occasional crash by incorrectly declaring the function NSFDbGetModifiedNoteTable in LotusScript code.

C.        Greatly improve performance when loading and editing code that uses multiple LotusScript libraries.

D.        Crash when making a function call such as Call etc(Split(...)) when the parameter is "by reference" and inside the function this value is used in certain ways, including assigning it to a document field via = (note: using a Byval parameter instead of by reference, or using ReplaceItemValue instead of an assignment, does not cause a crash. Assigning the Split result to a temporary variable and passing this to the function, also avoids the problem).

E.        A Select Case statement using a "to" range of strings (Case "a" To "z") uses a case-insensitive compare, even though Option Compare Nocase has not been specified.

F.        Overriding a method that returns an object (NotesDocument for instance), is not possible if the base class is defined in a script library included by the derived class (compile fails). If they're in the same module, there's no problem.

G.        The DIR$ function in English Notes in Windows OS with international character support enabled, can't return filenames containing international characters (they are changed to "?").

H.        LotusScript code runs about half the speed on Unix (and presumably Linux) than on Windows, because it "yields" processor too often. Long operations like "New NotesDatabase" don't take longer, but regular statements doing math and logic are slower.

I.        Smallish memory leak when using dynamic arrays, worse if the arrays are of variants. Has led to crashes in at least one case.

J.        Enhance error reporting to display the entire LotusScript stack by default when an error occurs and to define a single application-wide programmable error handling event (perhaps in the database script).

Andre Guirard | 6 February 2008 02:00:00 AM ET | | Comments (52)


1) Fix these first
Theo Heselmans | 2/6/2008 3:17:58 AM


2) My List
Michelle O’Rorke | 2/6/2008 3:38:50 AM


3) For me
Julian Woodward | 2/6/2008 3:52:57 AM


4) Mine..thanks.
Tony Palmer | 2/6/2008 4:16:10 AM


5) My list - thanks Andre
Simon Boulton | 2/6/2008 4:22:38 AM


6) Answers
Dan King | 2/6/2008 4:24:20 AM


7) My choice
Karsten Lehmann | 2/6/2008 4:35:28 AM


8) My Choice
Ulrich Krause | 2/6/2008 4:41:00 AM


9) my Choice
Christian Brandlehner | 2/6/2008 4:56:21 AM


10) My choice
Thomas Bahn | 2/6/2008 4:56:46 AM


List of arrays performance degredation

Polymorphism: Methods with same name, but different parameter signatures

Static methods and attributes


Abstract methods and classes

11) Untitled
Alan Bell | 2/6/2008 6:07:00 AM

well some of them sound like nasty buffer overflow bugs that really need fixing, but in terms of doing new stuff better


12) My Choice
Keith Smillie | 2/6/2008 6:07:05 AM


I'd like to second Thomas' additional choices :-)

13) fix these
Alan Bell | 2/6/2008 6:07:14 AM

well some of them sound like nasty buffer overflow bugs that really need fixing, but in terms of doing new stuff better


14) My choice
Barry Lewin | 2/6/2008 6:54:43 AM


15) C, C, C, C, C, C, C and then the rest...
Nathan T. Freeman | 2/6/2008 7:03:02 AM


Frankly, if there are known performance improvements for Lotuscript, I can't see how they're not at the top of the priority list. You do understand that the NUMBER ONE complaint about Notes 8.0 is performance, right?

The user's experience of performance isn't about some particular aspect being slow. It's about EVERY aspect being slow. So speeding up *anything* improves the user experience, even if it was slower in an old version that the user accepted.

16) Native crashes first, wrong native runtime semantics second, performance 3rd, C API-related and enhancements last
Richard Schwartz | 2/6/2008 7:12:46 AM


17) These are mine
Andrew Magerman | 2/6/2008 7:26:46 AM

JGFC for me!

18) My choices
| 2/6/2008 7:37:20 AM


Regarding J, even if the stack trace isn't a default action, could we make an Lsi_info(14) equivalent for GetThreadInfo? So getting a stack trace is at least a supported thing?

19) My choices
Julian Robichaux | 2/6/2008 7:37:42 AM


Regarding J, even if the stack trace isn't a default action, could we make an Lsi_info(14) equivalent for GetThreadInfo? So getting a stack trace is at least a supported thing?

Oh, and thanks for asking!

20) CFIJ
Janko Stefancic | 2/6/2008 7:46:51 AM


21) I like ...
Harkpabst Meliantrop | 2/6/2008 7:53:47 AM

... Richard's approach in general, but still don't stick with these strictly logical principles. :-)


plus Thomas' list.

22) Plus I can’t type.
Harkpabst Meliantrop | 2/6/2008 7:54:46 AM

Should read:


23) JCD
Rob van den Heuvel | 2/6/2008 7:58:09 AM


24) Step back and follow more general rules
Ben Langhinrichs | 2/6/2008 8:29:39 AM

In general, there are rules of precedence that are worth following. For example, when I as a programmer do the right thing, does it work as it should? Those features generally need to get fixed before the cases where I do the wrong thing, as much as I like to make systems bullet proof. Under that logic, E, G and, and possibly I, should be high on the list. After that, performance on frequently used operations tends to take next priority, since it is not something a programmer can work around, whereas passing things incorrectly can be worked around, so under that rule, H and C should come next, probably in that order. After those things are dealt with, fix problems that make it more bullet proof, or enhance the ability to promote correct usage. This is far more of a judgement call, but I would tend to fix A then D then J then B then finally F, so my overall order would be E,G,I,H,C,A,D,J,B,F.

25) CJID
Mick Moignard | 2/6/2008 8:34:49 AM

CJID in that order, and then the rest in any order.


26) Choices
Jesse Gallagher | 2/6/2008 8:50:12 AM

Well, "A" is certainly the most terrifying, since it would cause problems "invisibly." After that, I'd pick "E" since, though I haven't run into it, Ben's point about doing the right thing is spot-on.

Though "J" would be nice, I've been able to get by without it, and so I'd say anything that's an actual bug should take precedence.

So, picking from just this list:


27) Calling C functions from Lotuscript
Nathan T. Freeman | 2/6/2008 9:20:02 AM

IMNSHO, anything involving calling C directly from Lotuscript is a low priority issue. Doing it at all is a hack of the first order anyway. And there's just no reason to prioritize crashes on < 0.1% of applications when there are performance issues with > 50% of applications.

I'm know I'll get some jeers for that, but it's my belief that anyone who's willing to make C calls from Lotuscript knows they're dabbling in black magic anyway, and understands the risk. Prioritize the stuff that impacts the bulk of customers, even if less severely. They suffer the death of 1000 cuts.

28) My Choices
Keith Nolen | 2/6/2008 9:20:49 AM


...and then polymorphism, interfaces, and abstracts as per Thomas.

I think the Unix performance issue (H) should definitely be a priority, as improved custom app performance is important for Domino to expand its installed base in the Linux/Unix world.

29) Re: Please vote on relative priority of these LotusScript issues
Charles Robinson | 2/6/2008 9:34:59 AM

DAICH, then I don't care

I agree with Ben. I see a lot of people putting down J as their top priority but the rest are bugs so they need to be fixed before you focus on developer candy. Don't get me wrong, J is awesome and I'd really really like to have it, but I'd also like to see Notes/Domino be less freakishly weird in how it behaves. I tore my hair out for *DAYS* over both A and D.

30) Untitled
Chris Hart | 2/6/2008 10:20:46 AM


31) JCE
Peter Presnell | 2/6/2008 10:58:35 AM


32) The 2 in my list...
Mael | 2/6/2008 11:16:35 AM


33) These *really* don’t seem like good priorities.
Brian Miller | 2/6/2008 11:18:12 AM

Fix this first, second, and third.

{ Link }

ONLY after that, ICHDJFH and forget the rest.

I'm with Nathan - all C-call stuff comes dead last.

Also, it scares me that you need to prioritize these at all with our input. They're mostly bugs, and should just all be fixed ASAP, in whatever order they can be done the fastest on average.

Our input on priority should be for enhancements to the language, not bug fixes. Will there ever be enhancements to the core LS language, to bring it in line with what's available for scripting languages in 2008?

In addition to full OO features as above (poly/innterfaces/abstract/static), I would add functions as first class objects, and autoboxing/autocasting to my want-list.

34) Priorities
Andy Broyles | 2/6/2008 1:07:54 PM


35) Priorities
Carlos L Rivera | 2/6/2008 1:17:59 PM


36) Priorities
Gerald Mengisen | 2/6/2008 1:41:49 PM


37) H then C if nothing else
Scott Hooks | 2/6/2008 2:51:03 PM

What's the fastest growing Domino server platform? Linux. What do virtually all business critical Notes apps rely on? Lotusscript. If you are telling me that my Lotusscript app will perform half as well on Linux as it would on Windows and that's IBM's fault, then I don't see how anything else is more important.

38) I second Ben Langhinrichs lisr=t
Lars Berntrop-Bos | 2/6/2008 4:49:34 PM

Bugs first features second, so:


39) Priority and C usage
Rob Goudvis | 2/7/2008 12:41:14 AM


If you are not afread to see your client crashes and red-screens, you can discover a whole new world when you dive into the C-functions. It would be much easier when the documentation also supplied the Lotusscript declaration of these C-functions. It is not always straightforward to "translate" the declaration from C-style into LS-style.

40) Priorities
Jan Van Puyvelde | 2/7/2008 3:28:45 AM


"D" sounds a lot like a problem I often get with the Replace function (using strings and variants containing strings). The workaround is also similar.

41) re: These *really* don’t seem like good priorities.
Andre Guirard | 2/7/2008 8:38:02 AM

The SPR KGUT6HWKUZ mentioned in that technote, is listed as fixed in 7.0.3, and I believe hotfixes have been made available to some customers.

42) C, C , C ....and H
Michael Bourak | 2/7/2008 9:42:50 AM

C is my "mandatory" to improve and promote Object Oriented usage in LotusScript...

H as linux is becoming a more and more used platform so it must be "on par" with windows.


43) Priorities
Vitor Pereira | 2/7/2008 10:39:06 AM


44) In principle, I agree with Ben’s logic.
Andrew Brew | 2/7/2008 5:50:15 PM

Pragmatically, this is what I care about...


45) Priorities
Jens Winkelmann | 2/7/2008 7:45:19 PM


Harkpabst Meliantrop | 2/8/2008 2:25:46 AM

"The fix disables, by default, the fix for SPR KGUT6HWKUZ. Note: The fix does allow you to re-introduce the fix for KGUT6HWKUZ by using the Notes.ini parameter "WebArrayCleanup=1" BUT its use will result in the performance issue described in this document."

I read this as: You can still have only one, but not both issues fixed.

47) JCHE
Amy Weston | 2/8/2008 2:55:56 PM


48) Untitled
| 2/8/2008 7:25:12 PM


A note about G - The other file system LS commands (FileCopy, Kill, etc.) don't support unicode filenames either. I've submitted an enhancement request for these and created some workarounds (e.g. using the NotesStream class to open a unicode-filenamed file and then truncating it happens to delete it). Overall it's pretty sad that the standard LS file commands don't support unicode, though.

And the C API stuff can definitely take a back seat. We've used plenty of it for years here, and there's plenty of workarounds for the "bugs" (mostly inconveniences, really) that do exist.

Polymorphism would rock, as would being able to define a class that inheirits from a Notes class (e.g. "Class MyMegaNotesDocument as NotesDocument).

49) Revised
Julian Woodward | 2/10/2008 8:13:57 AM

Having re-read this, I'm adding 'G' to my list, thus:


50) JCI....
Sean Burgess | 2/11/2008 4:41:21 PM

And then the performance issue with lists

51) JFC
Mirek Navratil | 2/12/2008 10:00:06 AM

.. then the rest.

Plus enhanced OOP support and class browser (collapsible class method/properties) if I can ask.

52) G is a real problem in developing an international application
Veli-Veikko Niskanen | 4/10/2008 7:12:22 AM


Not only Dir$ but also Kill and other LotusScript file handling related functions. To move an attachment file from one RT item to another you need to extract it to the filesystem (C: drive). And then re-embedd it. These COM methods work fine with filenames with unicode characters. But then you cannot cleanup your filesystem afterwards with Kill.

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact