Add support for gauge metric in static-exporter

[gauravgpta93]

Add support for gauge metric in static-exporter
Keep default as counter to avoid any changes for other places

[jdbaldry]

nit: for consistency with the other withFUNCTION methods, perhaps it should be just withType and not withMetricType?

[Duologic]

You could set this value below and require withMetricType instead of overloading the constructor.

[jdbaldry]

Is there a reason to prefer that over having all the arguments in the constructor?
I'm not sure I see how metricType is different from description or name except that the library originally only supported counter types.

In other words, why have:

metric.new('NAME', 'DESCRIPTION') + metric.withMetricType('TYPE')

when you can just have:

metric.new('NAME', 'DESCRIPTION, 'TYPE')

[jdbaldry]

Also, to help me understand our patterns better. Why does the constructor do:

self.withName(name)
+ self.withDescription(description)
+ self.withMetricType(metricType)

instead of:

{
  name: name,
  description: description,
  type: metricType,
}

I am thinking it's to use the public API presented by the object so that if withName ever does validation, the constructor also does the validation without refactor?
In that case, should we have some convention of indicating that the type, description, and type fields shouldn't be modified except through that public API. Perhaps they should be fields within a hidden _internal field or something?

[Duologic]

Is there a reason to prefer that over having all the arguments in the constructor?

I'll answer with a question: At what point do we stop adding things to the constructor?

My rule of thumb is to only add arguments to the constructor that are strictly required to create the object. Then create functions for changing the default values of the returned object.

Why does the constructor do ?

For small objects it doesn't matter that much I guess, for bigger objects these functions may encapsulate larger chunks of code. Opting to ~always use the functions increases consistency. I'm not too nitty-gritty on that, especially for manually written libraries.

There is a benefit on composability. Let's say the user wants to prefix the name for all instances from a library.

In the object approach, they have to override the constructor:

local prefixLib =
  lib + {
    new(name, description):
      lib.new(name, description) 
      + { name: 'prefix-' + name },
  };

With the function approach:

local prefixLib =
  lib + {
    withName(name):
      { name: 'prefix-' + name },
  };

I prefer to do the latter.