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

Add Resource entity #240

Merged
merged 9 commits into from
Jul 10, 2023
Merged

Add Resource entity #240

merged 9 commits into from
Jul 10, 2023

Conversation

kovstas
Copy link
Contributor

@kovstas kovstas commented Jun 5, 2023

It appears that we need to validate attribute values for resources, but I couldn't decide on the appropriate location to do so. It would be better to add a smart constructor for the attribute itself in the following pull requests, rather than adding validation for already created attributes within the resource's constructor.

@kovstas kovstas marked this pull request as draft June 5, 2023 23:17
@kovstas kovstas marked this pull request as ready for review June 6, 2023 19:37

/** An immutable collection of [[Attribute]]s.
*/
final class Attributes private (
Copy link
Contributor

Choose a reason for hiding this comment

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

Currently, most methods use varargs, e.g:

def resourceSpan[A](name: String, attributes: Attribute[_]*)

I wonder whether we should offer a new alternative too:

def resourceSpan[A](name: String, attributes: Attributes)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To be honest, I would completely replace Attribute with Attributes. Attribute looks like an unnecessary wrapper to me because, from my perspective, users are more interested in using a collection that provides interfaces for accessing particular values by keys or iterating over all of them. I can imagine that It might be useful as a smart constructor which validates passed values, but the collection can do the same. Maybe I don't see a use-case for it.

build.sbt Outdated Show resolved Hide resolved
@iRevive
Copy link
Contributor

iRevive commented Jun 7, 2023

Excellent work! Looks good to me

@armanbilge
Copy link
Member

Ross suggests in #199 (reply in thread) that we should target this to main after all. We will use another strategy to break the tracing work into smaller PRs instead.

@armanbilge armanbilge changed the base branch from sdk to main June 7, 2023 18:20
@kovstas
Copy link
Contributor Author

kovstas commented Jun 7, 2023

Ross suggests in #199 (reply in thread) that we should target this to main after all. We will use another strategy to break the tracing work into smaller PRs instead.

I've added NoPublishPlugin to the sdk-common module.

Copy link
Member

@armanbilge armanbilge left a comment

Choose a reason for hiding this comment

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

Sorry for the slow review cycle! Had a few more thoughts, but overall looks good!

Copy link
Contributor

@iRevive iRevive left a comment

Choose a reason for hiding this comment

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

Looks good, thanks!

Copy link
Member

@armanbilge armanbilge left a comment

Choose a reason for hiding this comment

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

Thanks for iterating! Looks good, sorry I still had a few nitpicks but all very minor and non-blocking.

@armanbilge armanbilge merged commit e64156a into typelevel:main Jul 10, 2023
8 checks passed
@kovstas kovstas deleted the sdk-resource-class branch July 11, 2023 06:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants