[swift-build-dev] [swift-dev] Right list?

[Erica Sadun]

I think names like "Daniel Dunbar's String Extensions" is great when talking in English about a specific extension but I think the actual name should be as simple and elegant as possible without overlapping with built-in keywords.

import String // bad, name conflict
import StringUtilities // good. simple, gets to the point, it will be very rare that you'll want to import several of these, but it may happen
import org.sadun.StringUtilities // I can live with this but I'd rather import with a custom name established in dependencies
import org.sadun.StringUtilities as SadunStrings // also okay, again, the custom name will be used and it's unique and short
import `Daniel Dunbar's String Extensions` // bad, especially when you have to reference it
import `Daniel Dunbar's String Extensions` as DunbarStrings// slight improvement but not much, it's ugly, clunky, etc.
import SadunStringUtilities // This is why we're trying to leave Cocoa behind. If we have to namespace stuff just to avoid conflicts, we've already lost

-- E


> On Feb 26, 2016, at 3:27 PM, Max Howell <max.howell at apple.com> wrote:
> 
>> Can you explain a little more about your motivation for this?
>> 
>> I understand that "SwiftString", as a package, may be something which is likely to conflict. It isn't however clear to me that most packages fall into that category, or that it is even desirable to support features that encourage it.
> 
> I don’t mean to intercept Erica here, but I wanted to chime-in.
> 
> For me, my motivation is we don’t have a single index, so it is quite likely that module names will collide at some point.
> 
> We need some solution for this. Originally I was thinking, well lets allow overrides for module-names, which is still an option, but it is not as simple as I originally hoped since any packages that depend on that module in a deep tree will require either:
> 
> 1) Swift-the-language support for the rename.
> 2) Or a preprocessor step in the Package Manager that renames module imports in affected packages.
> 
> Namespaces are more elegant, especially if by default you don’t have to care. Packages would only have to care if they import two modules with the same name, and this would be discovered by the package author, not by the end-user who just happened to depend on the wrong combination of packages.
> 
> Also, personally, I want people to call their packages “StringExtensions”. Currently the iOS development world is filled with silly names for packages, and this partly happens because the good names are already taken. People would instead say “Daniel Dunbar’s String Extensions” and for me, that is what the package should be called.
> 
>> For packages like "libjpeg", "LLVM", "OpenGL", "ncurses", "zlib", it seems like having one global namespace is OK, and even useful. As a Python user, for example, I have never been bother that the Python package index is a global namespace.
> 
> Yes, this is separate (for me). And handled by module map packages.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160226/7b48415c/attachment.html>