In the standard library, you can find things like WindowServices and DebugUtils, both of which, viewed generally, have similar purposes: They provide methods you can call to do useful things. So, why are some named '*Services' while are named '*Utils'? Here's the key convention: Things suffixed with Utils should be size 0, while things suffixed with Services have a non-zero size.

Of course the elephant in the standard library is EventWindow. That name violates this convention, because it has neither 'Utils' nor 'Services' as a suffix; it gets away with the violation because it predates the whole naming convention. But, since it is size 0, we should think of it like EventWindowUtils and not EventWindowServices.

Rule of Thumb: Prefer data members for *Utils, and local variables for *Services.

Unless you have a specific reason not to, prefer to declare *Utils (which includes EventWindow) as data members, and to declare *Services as local variables in a method. So, for example, prefer this:

Evaporator.ulam

element Evaporator {
  EventWindow ew;
  Void behave() { ew[0] = ew[1]; }
}

over this:

element Evaporator {
  Void behave() { 
    EventWindow ew;
    ew[0] = ew[1]; 
  }
}

even though, in this case, both versions behave identically.

The reasoning for this “Make *Utils data members” guidance has an obvious point and a subtle point:

The obvious point is that since a *Utils is size 0, it doesn't impact the atomic bit budget at all, so it's harmless to make them data members. Furthermore, placing them as data members makes them available to all methods with a single declaration, and can provide a systematic place (e.g., at the top of the class) for all *Utils declarations.

The subtle point is that even though a *Utils is size 0, when a *Utils method is called, the self object passed into the called method can differ depending on how the *Utils was declared. For example, this definition:

Announcer.ulam

  element Announcer {
    DebugUtils du;
    Void behave() { du.printContext(); }
  }

produces output like this:

log
log

which is pretty noisy but could conceivably be useful. By contrast, this definition:

element Announcer {
  Void behave() { 
    DebugUtils du;
    du.printContext(); 
  }
}

produces output like this:

log
log

which is less useful, at best.