Regards (From mobile)
> On May 20, 2016, at 5:48 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > >> On May 20, 2016, at 10: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. > > What benefits do namespaces provide that empty enums and / or submodules do > not? This isn’t clear to me and I think it is an essential part of the case > that must be made. > > Nobody is arguing that we don’t need a way to isolate names. The question is > whether namespaces are the right mechanism for doing that or not. Yes, IMO they would, for the simple fact that they would be a easy to recognize boundary line where the linking behavior would changes (this is what modules do). Because of modules being tied to the dylib behavior, it means namespaces would have to follow suit and basically limit themselves to be submodules (I'm sure something could be done to pretend that 2 separate dylibs form a single namespace, but i am not sure this is the best way for someone to use their time, not to mention how it would break all the work done in the last couple years with profile optimizations). > >> >> >>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
