[swift-evolution] [Discussion] Namespaces

T.J. Usiyan griotspeak at gmail.com
Fri May 20 10:08:39 CDT 2016

+1 for namespaces.

On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

> > On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > When you have namespaces Car and Animal and each contains a class called
> List, IMHO there should be classes CarList and AnimalList. It's more
> verbose, but you imediately know which class is being used in opposite of
> just using List.
> Why not use Car.List and Animal.List when its unclear from context? With
> Swift’s type inference you don’t often need to specify types anyway so your
> editor will know which list type you’re using based on how you obtained it.
> That said it does depend on the purpose of each List; do they have any
> commonality? They could for example both be generic List implementations,
> but were never factored out into a common module. If however they are
> specialised constructs specific to cars or animals, then the prefix may
> make most sense.
> For example, in the libdispatch thread the naming of
> Dispatch.DispatchQueue was queried, however this isn’t a general purpose
> queue type, it’s more specialised than that, so a name of “Queue” doesn’t
> convoy enough information, just as List might not. But it depends on what
> it actually does, which a basic example tends not to include ;)
> Anyway, I’m +1 for namespaces everywhere, some names can be common. For
> example Node could be related to trees, physics engines and all sorts of
> constructs. “Node” may be a perfectly fine name for these. That said, these
> are sometimes tied to specific types in which case nesting them may make
> more sense, which I believe is already being addressed (currently we can’t
> nest generic types)? It’s certainly not as simple as it can appear!
> _______________________________________________
> 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/20160520/13811a4b/attachment.html>

More information about the swift-evolution mailing list