Check public APIs for Swift friendliness

[philipphofmann]

Description

Go through all public APIs and check, if they conform to Swift naming guidelines. Double-check if we can avoid breaking changes or if a breaking change is worth the effort.

• [ ] https://github.com/getsentry/sentry-cocoa/issues/1842
• [ ] https://github.com/getsentry/sentry-cocoa/issues/1100

[philipphofmann]

We could already create overloads right now and deprecate the not Swift-friendly APIs in 8.x.x.

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[philipphofmann]

@sindresorhus, we are currently working on this task. As you voted with 👍, are there any APIs you can point out that are not Swift-friendly and that you would like to change?

[philipphofmann]

We now prefixed User and Client with Sentry. We renamed Client to SentryClient because we have SentrySDK and SentryHub and there could be naming collisions. We renamed User to SentryUser as almost every application has a user class.

Does the same apply to Event? I guess many apps could also have an Event class. Maybe we should also rename it to SentryEvent?

The following classes are very specific to Sentry. They could have a prefix Sentry, but most users don't interact with them, so the chances of naming collisions in the same Swift file are low. I think we could keep them, cause renaming them causes plenty of hassle in our test code:

• Exception
• Mechanism
• MechanismMeta
• Frame
• DebugMeta

What do you think @brustolin and @kevinrenskers?

[kevinrenskers]

To be honest I'm not sure about the User rename. Name collisions are not really a thing in Swift, as you can always namespace it: Sentry.User.

Have we had user complaints about the User class?

The Client rename does make a lot of sense to me.

Exception is very generic but yeah with namespaces it's fine.

[philipphofmann]

To be honest I'm not sure about the User rename. Name collisions are not really a thing in Swift, as you can always namespace it: Sentry.User.

Yes, but user is pretty common. I think that's fine. I would keep the others.

Have we had user complaints about the User class?

Yes one user, but that shouldn't be the reason why we do it. We should do the right thing.

[brustolin]

I think we should change Event to SentryEvent, Exception maybe. Im fine with the others.

as you can always namespace it: Sentry.User.

Yeap, but this is annoying.

[philipphofmann]

Java, Dart, and .NET also have SentryEvent. JavaScript on the other hand has `Event.

I'm also fine with keeping Event. It causes plenty of hassle, and what's the benefit? On the other hand, we just renamed client and user, so it would be consistent.

[kahest]

Check if Swift supports only prefixing one e.g. User class used in a file, e.g. prefix Sentry.User and keep instances of other User classes as User. If possible, then revert renaming of SentryUser, otherwise keep to avoid devs needing to prefix their own User classes (potentially within existing implementations).

[philipphofmann]

@brustolin, you now merged https://github.com/getsentry/sentry-cocoa/pull/2462. So we can close this.