SlightlyLoony
Tera Contributor

find_real_file.pngFor three days now, I've delivered what some people consider a form of bloodless torture: a description of bitwise (aka "binary") operators, complete with a bunch of examples in hex and binary. This was actually in response to a request from a reader, whose motives you may interpret as you desire. But I didn't delve much into why one might want them. So in this post I'll give you a few examples of how you might find this arcane knowledge useful when working with Service-now.

I've run into the need (or desire) for manipulating bits in three general places:

  1. Foreign Data: The examples I'm most familiar with come from Discovery and Runbook, but I suspect there are similar examples to be found in imported data. Here's one example: when querying the status of a printer with SNMP, you might get back a numeric field called STATUS. When you look at the documentation for the device, you might find something like this: "bit 0 = online, bit 1 = busy, bit 2 = needs paper, bit 3 = needs toner, bit 4 = overtemperature, bit 5 = disk full, bit 6 = mechanical failure". Let's say you're writing a runbook activity that needs to check if the printer has any kind of problem. Looking at that documentation, you can see that if any of bits 2 through 6 are set in the STATUS field, that printer is in trouble. But how can you tell? If the status is in the variable named 'status', this code will call the function 'trouble()' when there's a problem:

    if ((status & 0x07c) != 0)
    trouble();

    See the preceding posts if you don't understand why that works.
  2. Java classes: Some Java classes that you might want to call from JavaScript have parameters (often called 'flags'). An example of this is the Pattern class, used for regular expressions. These parameters use bits to control various behaviors of the class being called. If you need to set a couple of bits, you can do it with arithmetic operators, but what you're doing is more explicit if you use bitwise operators. Here's an example both ways:

    var DOTALL = 0x20;
    var MULTILINE = 0x08;
    var regex = "^.*?basic(//d+).*$";

    // with bitwise operator...
    var pat = Packages.java.util.regex.Pattern
    .compile(regex, DOTALL | MULTILINE);

    // with arithmetic operator...
    var pat = Packages.java.util.regex.Pattern
    .compile(regex, DOTALL + MULTILINE);

    A subtle difference, perhaps — but some would argue that the bitwise operator provides a clearer declaration (to someone reading the code) of what you're doing. Furthermore, using the bitwise operators allows you to do something that's occasionally quite useful, like using the XOR operator to flip a bit, or using the AND operator to mask out some bits.
  3. State information: You may have the need sometime to keep track of the state of something in your JavaScript code, where that state has several components. For instance, imagine that in your code you needed to keep a list of tasks, and each of these tasks could have any combination of several on/off states: costs something, assigned to a contractor, requires purchase from a vendor, and the CEO is waiting on this. If any of these states is 'on', then it's a special task. You could create a boolean property for each of these states. Then to see if this is a special task, you might have code like this:

    if (x.costs || x.contracted || x.purchase_required || x.ceo_interest)
    do_special();

  4. Another way would be to have a single numeric state property (we'll call it 'state') where each condition is assigned to a bit. We might say that bit 0 is for costs, 1 is for contracted, 2 is for purchase required, and 3 is for CEO interest. The same test would then look like this:

    if (x.state != 0)
    do_special();

    And to set a particular state, you might see code like this (to set purchase required):

    x.state |= 4; // set bit for purchase required...

    This style of coding on/off states is hard to justify when you have only a few states to worry about. But when you have (say) 18 states, this representation results in considerably more concise code (especially the tests).

  5. Now...did I make it worse, or better?

2 Comments