[swift-evolution] Fixing modules that contain a type with the same name

[Xiaodi Wu]

On Mon, Jun 20, 2016 at 11:12 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:

> I think that it takes some chutzpah to declare that your B-tree is
> authoritative enough that it should be called "BTreeCore".
>

I don't know why it sounds more authoritative than `BTree` itself. If you
and I both name a type `BTree` (very logical), then it's up to the module
name to distinguish them. But if we both think it's 'obvious' that our own
`BTree` type should be the one that's in the module named `BTree`, isn't
that a claim to authoritativeness?

I also by far prefer BTree to MyBTree or BTreePackage; of course these are
> all possible workarounds for a name resolution *bug*, but they certainly
> don't sound great to me.
>

I'm not entirely convinced that this definitely falls into the category of
a bug. I'd imagine there's a cogent argument why type names and module
names should be mutually distinct; it's too late in the evening for me to
come up with one at the moment.


> I'm also not suggesting that you can just do away with the "kit" or "core"
> in a module name: I'm saying that I find it intuitive to take the main
> class of a package and name your package after it. It's not like you can
> instantiate the Web from WebKit!
>
> Either way, these <https://github.com/kirsteins/BigInteger> things
> <https://github.com/lorentey/BTree> happen and I don't see anything
> fundamentally wrong with it. I'd prefer a fix to a restriction.
>
> Félix
>
> Le 20 juin 2016 à 19:21:45, Xiaodi Wu <xiaodi.wu at gmail.com> a écrit :
>
> On Mon, Jun 20, 2016 at 9:08 PM, Félix Cloutier <swift-evolution at swift.org
> > wrote:
>
>> I'm trying to reply to everybody in this message.
>>
>> I think that it's a rather common and intuitive thing to name a module
>> after its most important class, especially for small-ish packages. What
>> would you call a package that provides a BTree, or a BigInt, and not much
>> else?
>>
>
> BTreeCore, BTreeKit, BTreePackage, MyBTree, MyBTreeCore, MyBTreeKit,
> MyBTreePackage...
>
>
>> I'd also make the case that ManagedObject wouldn't be an awful name for
>> CoreData, or Animation for CoreAnimation.
>>
>
> On the contrary, I think these show that some sort of prefix or suffix is
> greatly beneficial. IMO, Data would be an absurd package name. Note how
> it's WebKit, UIKit, SpriteKit and not Web, UI, Sprite.
>
>
>> If your package is big enough that it benefits from having a single class
>> that serves as the entry point to it, it would also make sense to call it
>> the same thing as your package.
>>
>> I don't really like preventing modules from having a class with the same
>> name, precisely because I think that it's an intuitive thing to do.
>>
>> I could go with Module::Class too, given that : is not an operator
>> character.
>>
>> Paulo, given that I'm not sure about the direction that you're taking,
>> it's a little hard to come up with a good name. "Disambiguating namespaces"
>> or "namespace selection" or something like that could be a good start,
>> maybe?
>>
>> Félix
>>
>> Le 20 juin 2016 à 17:33:03, Paulo Faria <paulo at zewo.io> a écrit :
>>
>> Yeah! I’m working on a formal proposal that would solve the same problem.
>> Jordan, the problem he described is exactly like the one you explained to
>> me, haha. Now I’m a bit confused about how the proposal should be called.
>> Have any suggestions? What title could fit the two use cases we mentioned.
>> By the way, can you see any other use case that would be solved with the
>> same solution?
>>
>>
>> On Jun 20, 2016, at 9:25 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>>
>> I've been encouraging Paulo Faria to mention this case in his push for a
>> way to disambiguate extension methods, with the thought being we could then
>> use the same syntax to differentiate top-level names as well.
>>
>> I'd also be happy with the "import as" syntax. The underscore syntax
>> seems a little opaque, but I suppose it wouldn't come up very often.
>>
>> Jordan
>>
>>
>> On Jun 17, 2016, at 19:52, Félix Cloutier via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Hello all,
>>
>> I recently ran into a bug <http://stackoverflow.com/q/37892621/251153> that
>> leaves me unable to fully-qualify the name of a type. If you import a
>> module named Foo that also contains a type named Foo, attempts to
>> fully-qualify any name in the Foo module will instead attempt to find
>> something inside the Foo type. This bug has already been reported
>> <https://bugs.swift.org/browse/SR-898>.
>>
>> Here's an example with Károly Lőrentey's BTree module (which also
>> contains a BTree type) that I encountered while trying to use the
>> OrderedSet type:
>>
>> let set = OrderedSet<Int>()// error: 'OrderedSet' is ambiguous for type lookup in this context// Found this candidate: Foundation.OrderedSet:3:14// Found this candidate: BTree.OrderedSet:12:15
>>
>> To solve this, you would normally write BTree.OrderedSet, but now Swift
>> thinks that BTree is the BTree type, not the BTree module:
>>
>> let set = BTree.OrderedSet<Int>()// error: reference to generic type 'BTree' requires arguments in <...>
>>
>> Any fix will require a change to the language, and as Jordan Rose stated
>> on the bug, it "needs design", so I would like to bring up the issue and
>> discuss possible solutions.
>>
>> I can see several options (leaving "do nothing" aside, since I believe
>> that this needs to be resolved):
>>
>>
>>    - Prevent modules from containing a type with the same name
>>    - Allow modules to be imported under different names (`import BTree
>>    as BTreeModule`, `import BTreeModule = BTree` or any similar syntax)
>>    - Create a new syntax that indicates that you're naming a module, not
>>    a type (like `_.BTree.OrderedSet`)
>>
>>
>> Thoughts?
>>
>> Félix
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160620/f0e01d96/attachment.html>