This would be out of scope for Swift 3 right? Or is this relatively "easy" to implement?
Brandon Sent from my iPad > On May 20, 2016, at 11:27 AM, Tony Allevato via swift-evolution > <[email protected]> wrote: > > Another use case to consider: code generation. There, namespaces can be > vital; they let you isolate code that you may have no real control over (for > example, data models that correspond to remote services) from the rest of > your code to avoid collisions. In some cases that can be achieved by putting > the shared code in its own module, but if that data description format has > hierarchical namespaces/packages of its own (Google's protocol buffers, for > example), then the lack of namespaces forces the code generator to come up > with contrived schemes for naming nested entities (like the Objective-C > implementation, which uses underscore_delimited_names). The result is that > Swift code using those services would look *very* unnatural. > > >> On Fri, May 20, 2016 at 8:08 AM T.J. Usiyan via swift-evolution >> <[email protected]> wrote: >> +1 for namespaces. >> >>> On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution >>> <[email protected]> wrote: >>> >>> > On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution >>> > <[email protected]> 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 >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
