Best Pratice - Should I use globals?

HCL Domino Domino Forum
1

Hello,

honestly I do not think I have used Globals since taking my LotusScript course years ago. Granted I have never really created any huge databases.

But what is everyones feelings towards them? Is it better to use Globals?

Current database I am working on is just growing and growing and I am nearing the point of no return. Is it worth trying to rewrite some code and start using them? Or just not worry about it.

Thanks

2

Subject: Best Pratice - Should I use globals?

In a perfect world, I think of it this way:1) If I use a function/sub in more than a couple agents/forms, then I try to put it into a library. Of course, the downside is that I can get a big library with many agents/forms only using a couple things each, but I usually find I have a handful of really common functions and then a handful of rarely used functions, so the latter might just remain in the actual agent/form.

  1. I use globals so that I don’t have to pass around the actual string, item, doc, db, etc. If my code doesn’t have subs/functions that require those handles, then I don’t bother with globals.

hth,

raphael

3

Subject: RE: Best Pratice - Should I use globals?

My perference is to give variables just the amount of scope they need.

Generally the session and current db/doc end up as globals.

Everything else is declared where it is first used.

Frunobulax

4

Subject: RE: Best Pratice - Should I use globals?

I follow this practice as well and some of my custom class instances end up as globals, too.

5

Subject: RE: Best Pratice - Should I use globals?

I’m not sure why the size of your database, or the complexity of the design, is a factor in this decision.

I tend to avoid using globals, both for performance reasons and because it makes code harder to maintain. Once something is declared as a global, it could be used anywhere; if it’s in a script library, it could be accessed by any script that uses that script library. This makes it difficult to predict the effect of changing how the global is handled, unless you analyze all your code to see where it might be used. Like Frunobulax, I like to give variables only as much scope as they need.

Yes, you don’t necessarily want to pass as parameters into every subroutine, every bit of information they need to do their job. A lot of times it makes more sense to store them centrally. But a lot of what people think they need globals for, can be better addressed by use of custom classes. If you have a group of routines that need that data item, think about whether there’s an associated object that could contain the shared data. Try to conceptualize the grouping of data and functionality as something you could give a name to. Because you can declare these items as private within the class, it’s a lot easier to be certain that you’re seeing all the code that references it, together in one place.

I would not declare the session object as global. There is already only one session object, so when you create a new one, you’re just attaching to the existing session, which is very fast to execute. Since access to a global is slower, and you typically use them more times than you declare them, you’re not gaining anything by making the session a global.

Some things I have made globals are:

Central error-logging objects and “factory” objects. Note I am still using a class in this case; it’s just that there’s only one instance of the class, which is shared by everyone. If data is to be read-only, or if certain actions have to accompany a write, the class can guarantee this by its methods.

Rich text styles that I plan to use repeatedly (though again, it often makes sense to include these in a “report generator” class and initialize them in the constructor).

Reference data which is intended to be initialized on startup and read in various places in the code. For instance, if you have a PirateNameGenerator class* that randomly creates pirate names by selecting from lists of adjectives (Long, Loud, Ornery, Jolly…) first names, and last names, you could store those lists in globals, since it is time and memory-consuming to initialize and store them separately every time someone creates a “New PirateNameGenerator” object. And of course, there could be a global store of already-used names to prevent duplication, which all the objects would share. It would be better to do this with static class members, but alas, these are not supported in LotusScript.

  • Why do this as a class rather than just creating a function to return a random name? Because the PirateNameGenerator class is derived from the NameGenerator class, and you also have a TestDataGenerator class with a method which takes a NameGenerator as argument. You can use that same class to generate random sample data containing pirate names, rock star names, hobbit names, blues musician names, or whatever other type you might derive. The data generation method of TestDataGenerator would just invoke the Generate method of whatever object you pass to it.