I think that it takes some chutzpah to declare that your B-tree is authoritative enough that it should be called "BTreeCore". 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 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...@gmail.com> a écrit : > > On Mon, Jun 20, 2016 at 9:08 PM, Félix Cloutier <swift-evolution@swift.org > <mailto:swift-evolution@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 <pa...@zewo.io >> <mailto:pa...@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_r...@apple.com >>> <mailto:jordan_r...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
