Notification protocol clashes with Foundation.Notification

[nhojb]

Describe the bug

Notification protocol clashes with Foundation.Notification 😔

To Reproduce

1. Import MCP into a file which already uses Foundation's Notification type.
2. Compilation fails

Expected behavior
It would be better to avoid generic protocol and type names to avoid clashing with well-known Foundation types.

[stallent]

Yeah, we ran into this as well. Trivial workaround, but honestly i'm not sure renaming to MCPNotification is any "better" than just doing it as MCP.Notification which is how we worked around the clash.

[nhojb]

Note that your work-around doesn't work because of #52 😆

So should be a trivial workaround. But it's still a pain point when importing MCP. And I notice that there are many "generic" type names in the package that are very likely to also clash with existing client code 🫤

Perhaps it demonstrates a limitation of Swift's "namespace" design (or lack thereof). But given that, I think it beholds library authors to think hard about their type names.

[stallent]

It does work but i wasn't clear enough. Apologies for the hasty response. lol. Here is my workaround and works ok with 0.7.0

import MCP

extension MCP {
    public typealias MCPNotification = Notification
}

and then just use MCP.MCPNotification as needed.

My comment was i'm not sure i prefer a top level MCPNotification vs just using MCP.Notification (which isn't possible after the Error rename where the new enum came in). Happy to clarify more if needed.

[mattt]

Hi @nhojb. Thanks for your feedback. #52 was a self-own, and I have a PR to fix that with #53.

I do wish Swift had something like Python's import aliases (i.e. from MCP import Notification as MCPNotification). But importing individual symbols on an as-needed basis is workable (except, you know, when a framework decides to export a type that shadows the module name 🥲).

At some point, it's a balancing of aesthetic preferences with functional requirements. Cocoa-style TLA prefixes are effective, but I don't miss them in modern Swift APIs. I'll make an exception for Error specifically because of its interactions with language primitives (#32), but I'm not eager to prefix everything if the impact is minimal or unlikely, and there are reasonable workarounds.

[mattt]

Just released 0.7.1, which removes the top-level MCP enumeration that prevented use of fully-qualified types like MCP.Notification. Thanks again for your feedback and patience 🙇