Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify that Scope is defined at build time #2878

Conversation

tigrannajaryan
Copy link
Member

I have seen several time a confusion around the nature of the scope and whether scope attributes can change at runtime.

The purpose of this PR is to make sure we all agree the scope is a build time concept, or if we disagree then explicitly specify what else the scope can denote and how its attribute can change at runtime.

@carlosalberto
Copy link
Contributor

(Although maybe "application initialization time" is more accurate than build time, etc)

@tigrannajaryan
Copy link
Member Author

(Although maybe "application initialization time" is more accurate than build time, etc)

I am actually going explicitly for "build time" since Scope is defined as "A logical unit of the application code". A unit of code is fully defined at build time. "application initialization time" would be different and would imply something like a process.id or thread.id is a valid Scope attribute, but I believe it is not and I want to prohibit it by this clarification.

Copy link
Member

@Oberon00 Oberon00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While technically I think the scope is implemented as a runtime entity in most languages, conceptually I agree it is clearly a build-time concept indeed.

@ahayworth
Copy link
Contributor

Since the scope is a build-time concept the attributes of the scope cannot change at runtime.

I think it's worth calling out that there are many languages that do not have a concept of "build time" in this way. For example, there is no equivalent concept of "build time" in Ruby; "application initialization" is the closest analogue we have. I understand the goals of the PR, but I do think we should find a way to define it that makes allowances for interpreted languages.

@tigrannajaryan
Copy link
Member Author

Since the scope is a build-time concept the attributes of the scope cannot change at runtime.

I think it's worth calling out that there are many languages that do not have a concept of "build time" in this way. For example, there is no equivalent concept of "build time" in Ruby;

It is not about "building" in the "compiling" sense, it is about "building" in the "developer writing code" sense. This is applicable to any language. If it is not clear we can make this more explicit.

"application initialization" is the closest analogue we have.

No, that's exactly the opposite of what I suggest. "application initialization" happens at runtime.

@ahayworth
Copy link
Contributor

It is not about "building" in the "compiling" sense, it is about "building" in the "developer writing code" sense. This is applicable to any language. If it is not clear we can make this more explicit.

No, that's exactly the opposite of what I suggest. "application initialization" happens at runtime.

Using "build-time" to mean "the time at which an application developer writes code" is strange to me. Typically when I see "build-time" I equate it to "compile-time" (or an equivalent linking or packaging step, depending on the ecosystem in question). I like your suggestion of making that more explicit - that avoids a lot of ambiguity. And would have prevented my comments in the first place. 😄

@github-actions
Copy link

github-actions bot commented Nov 2, 2022

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Nov 2, 2022
I have seen several time a confusion around the nature of the
scope and whether scope attributes can change at runtime.

The purpose of this PR is to mak sure we all agree the scope is
a build time concept, or if we disagree then explicitly specify
what else the scope can denote and how its attribute can change
at runtime.
@tigrannajaryan tigrannajaryan force-pushed the feature/tigran/clrify-scope-attrs branch from 86d090f to 1982c40 Compare November 2, 2022 16:43
@tigrannajaryan
Copy link
Member Author

Has enough approvals. Merging. Further refinements can be done in a future PR.

@tigrannajaryan tigrannajaryan merged commit 08a15ef into open-telemetry:main Nov 2, 2022
@tigrannajaryan tigrannajaryan deleted the feature/tigran/clrify-scope-attrs branch November 2, 2022 16:46
lmolkova pushed a commit to lmolkova/opentelemetry-specification that referenced this pull request Nov 3, 2022
I have seen several time a confusion around the nature of the
scope and whether scope attributes can change at runtime.

The purpose of this PR is to mak sure we all agree the scope is
a build time concept, or if we disagree then explicitly specify
what else the scope can denote and how its attribute can change
at runtime.
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
I have seen several time a confusion around the nature of the
scope and whether scope attributes can change at runtime.

The purpose of this PR is to mak sure we all agree the scope is
a build time concept, or if we disagree then explicitly specify
what else the scope can denote and how its attribute can change
at runtime.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants