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 convenience event emitting api to OpenTelemetryRum #892

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cleverchuk
Copy link
Contributor

Fixes #573

@cleverchuk cleverchuk requested a review from a team as a code owner March 17, 2025 13:01
*
* @param eventName The name of the event to emit.
*/
default void emitEvent(String eventName) {
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about doing this in Kotlin and collapsing all these methods into one and use default arguments?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it looks like that's very possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

FYI: it won't be very nice to Java users though.

Copy link
Member

Choose a reason for hiding this comment

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

you can add the annotation @JvmOverloads so kotlin generates overloads for the java callers

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It looks like that would require making the function a class method instead of being declare in an interface?

Copy link
Member

Choose a reason for hiding this comment

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

you can just do method overloads with kotlin anyway so its ok to convert it to kotlin

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh true that, you can make this interface an abstract class but not sure if that's what you want

i was thinking the same. however, i don't know whether others would want it to changed to a class.

you can just do method overloads with kotlin anyway so its ok to convert it to kotlin

it looks like that defeats the purpose of converting to kotlin?

Copy link
Member

Choose a reason for hiding this comment

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

it looks like that defeats the purpose of converting to kotlin?

i think we all want at some point that the codebase is kotlin only when it makes sense.
all new code ideally is kotlin, if its not a big pain.

your call here since it works already

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe for now just keep this in Java and we can convert the whole class to Kotlin at a later point. There might be some binary compatibility issues in that case, but we can do it in a version bump where doing some trivial compile time breaks are ok.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sounds good

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.

Make emitting custom events simple
3 participants