Telemetry doesn't have to start inside the global. In fact, while we're factoring it, I triggered a deadlock a few times while trying to read global information for telemetry purposes.

The time has come for someone besides tests to use this data!

The internal worker instance is now private: it's an implementation concern.

What is precedence_set?

This is the effective precedence of the value this option is currently set to.
For example, if this option was never set, the precedence will be "default".
If the same option is then set by programmatic configuration (Datadog.configure{}), it will change to "programmatic".
Then, again, if it is over, written by remote configuration, it will change to "remote configuration".

Now, the interesting part is that same option is then again remote configuration by programmatic configuration, it will not change value, given remote configuration has a higher precedence.

Let me know if this makes sense. Also, I expanded the in-line documentation of this class regarding precedence.

On another topic, it probably makes sense to simply rename me to precedence, what do you think? I would probably do that in a separate PR as, it will touch many files and related to this PR, but it's a very simple rename to do as a follow up.

Gotcha. Was just curious. No strong opinions at this point, so if you're confident on this, I'm interested to see how it works.

I like the use of a class. Nit, but does it make sense to initialize an object?

This pattern of initializing an object makes sense for more complex the telemetry events like AppClientConfigurationChange:

AppClientConfigurationChange needs information to be provided in two different contexts: first it needs to know what has changed in the source of that change (changes, 'remote_config'), then later it needs to receive the auto-incrementing seq_id:

Because these two sets of information exist in different contexts, I need a way to store the first set (changes, 'remote_config') and then merge it with the second set (seq_id).
So in this case, it makes sense to initialize the class and then call a method accepting a parameter with the remaining information.

That being said, most events are simple, like you mention for AppStarted, and don't actually need two sets of data to build the event, but in order to keep the API consistent, I had to add this flexibility to all events.

Let me know if this makes sense or if you have further suggestions.

I see: sometimes it has state attached. I suppose most of these events don't fire often, but if they ever fired as often as traces (crazy possibly, I know), then I was imagining this would apply more pressure to memory.

Still I do like the event as a parameter from a flexibility point of view.

Feedback is not blocking.

Should this be a class? Or could it be a module? (Given it doesn't introduce state.)

I think the hierarchy here is that events are true children of a base class: an event is a subtype of a Base event.

It can technically work as a module, but I think that it would create the misleading impression that events just so happen to respect the Base interface, when in fact all events are a subtype of a Base event.

I see, this got me thinking about Sandi Metz's take on inheritance/composition. Some notes surrounding her discourse on the subject that I could find:

Deciding Between Inheritance and Composition

Inheritance gives you message delegation for free at the cost of maintaining a class hierarchy. Composition allows objects to have structural independence at the cost of explicit message delegation.

Composition contains far few built-in dependencies than inheritance; it is very often the best choice.

With inheritance, a correctly modeled hierarchy will give you the benefit of propogating changes in the base class to all subclasses. This can also be a disadvantage when the hierarchy is modeled incorrectly, as a dramatic change to the base class due to a change in requirements will break sub-classes. Inheritance = built-in dependencies.

Enormous, broad-reaching changes of behavior can be achieved with very small changes in code. This is true, for better or for worse, whether you come to regret it or not.

Avoid writing frameworks that require users of your code to subclass your objects in order to gain your behavior. Their application's objects may already be arranged in a hierarchy; inheriting from your framework may not be possible.

On that very last point: is there a case where we might want to have independent trees of event behavior? I don't think immediately, no, but that would be a strong case for composition over inheritance. I suppose to me, it would be more a factor of keeping our options open in accordance to the principle of least harm: that composition would be less restraining.

Another way I think about the reason to do one over the other is state (e.g. instance variables).

• Does the base class define or maintain state? (Internal or otherwise?)
• Does it need some initialization (constructor or otherwise)?

If yes to either, then probably should be inheritance, because modules are not great at maintaining state. Otherwise consider using a module.

Some food for thought. Ultimately, we can always refactor this if it doesn't constitute a breaking change, so no blocker on my side if we can always change later without much pain.

Deciding Between Inheritance and Composition

It seems like the composition that she is discussing is about having a delegator object. And I'm not sure that that applies here because the need is for a consistent interface. There's almost no behaviour being delegated to the base class, is for subclasses to respect interface.

Both classes and modules would fall under inheritance, based on her definition above I believe.

Also, this whole thing is internal and constraint inside a single file, so factoring is trivial, and will likely not even affect unit tests.

Is there any versioning of the API within our code?

Yes, it's here:

Just FYI, when ported to 2.x, this will need to be updated.