On Mon, Jun 20, 2016 at 11:12 PM, Félix Cloutier <felix...@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...@gmail.com> a écrit : > > On Mon, Jun 20, 2016 at 9:08 PM, Félix Cloutier <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> 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> 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> 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 >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
