I personally dislike the habit of deliberately naming different classes using the same name within a single project/module/library, just using different namespaces - one should be able to deduct from the code *which* class is being used without excessive checking.
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. I don't have much experience with C++ and C#, but sometimes I have to dive into C# code and you can hear my teeth grind since there is a declaration of a variable of class List and you have no idea which List is this, since there are dozens of classes with this name. You don't always have the code in an IDE to resolve the symbol for you, sometimes you browse it on git, etc. Which is why I personally find modules sufficient in providing a way to prevent naming collisions, yet strict enough to discourage the habits of other languages described above. Hence for me -1 on introducing multiple namespaces within a single module. > On May 20, 2016, at 3:27 PM, Leonardo Pessoa via swift-evolution > <[email protected]> wrote: > > Adrian, I myself don't see a reason other than "Objective-C never had it so > why bother about it now?" Most (if not all) .net languages support optional > namespaces and even PHP began supporting it in version 5 (if I'm not sure if > the version is right). No technical reason against and I'm particularly in > favour too so let's hear the others in the group. > From: Adrian Zubarev via swift-evolution <mailto:[email protected]> > Sent: 20/05/2016 09:16 AM > To: [email protected] <mailto:[email protected]> > Subject: [swift-evolution] [Discussion] Namespaces > > I want to revive this topic. > > Is there any technical reason why we can’t have namespaces in Swift? I’ve > found just a few threads about namespaces, but most of them had arguments to > use modules instead. > > I’m fine with modules but they just don’t serve everything I would want to. I > can’t enforce the developer to use the modules name if there is no naming > conflict. > > I asked in the SwiftPM mail list for a easier Xcode integration of modules, > but the response is exactly the opposite for using modules for namespaces > (read below). > > If I’m building one huge project I don’t want to build a lot of different > modules just shiny namespaces and clean code. > > So I ask the community again why can’t we have optional namespaces? > -- > Adrian Zubarev > Sent with Airmail > > Am 19. Mai 2016 bei 22:33:19, Daniel Dunbar ([email protected] > <mailto:[email protected]>) schrieb: > >> Right now modules are most appropriately used at the same granularity that >> frameworks or shared libraries would be used in C/Obj-C/C++. This is the >> situation for which the variety of access control modifiers in Swift and >> things like Whole Module Optimization were designed for. While there are a >> lot of reasons to like modules as a way to provide namespaces, they really >> haven't been designed to provide these very fine grained namespaces. >> >> My guess is that the right answer here doesn't really involve the Xcode >> integration, but rather figuring out the right way that these concepts fit >> into the language in a first class way. I would expect concepts like >> submodules or namespaces to be language concepts that Xcode just exposes, >> not something that was coupled together. >> >> - Daniel >> >>> On May 18, 2016, at 12:37 PM, Adrian Zubarev via swift-build-dev >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> I’d like to discuss an idea that will make development in Xcode easier. I >>> assume that SwiftPM will see its Xcode integration when the final version >>> will be released. >>> >>> Problem I’ll try to describe is mostly about namespaces. Right now some >>> people abuses enums, struct or classes to create a namespace for a specific >>> need. >>> >>> class Reference { >>> class String { … } >>> class Character { >>> enum Error { … } >>> } >>> >>> private init() {} >>> } >>> >>> This will create a pseudo namespace for the nested types: >>> >>> * Reference.String >>> * Reference.Character >>> * Reference.Character.Error >>> >>> One could argue of using modules instead of abusing a class here, which is >>> a great argument. >>> >>> The problem that comes to my mind here is that we will have to create >>> subprojects inside our main project file and using the references to them >>> just to achieve that shiny namespace. >>> One could also use SwiftPM, which is awesome, but there is a need to >>> re-build the module if any changes have been done. As soon as we’ll create >>> some complex dependencies between different modules this will get messy. >>> >>> Before posting here I asked Joe Groff if there is any mailing list I can >>> use to discuss my idea. He told me this might be a good place, because I >>> was referring to the package manager. Then I’ve done my research to not >>> create any redundant thread, but I only found one topic about the >>> integration of SwiftPM in Xcode: >>> https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html >>> >>> <https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html> >>> >>> So here are my thoughts about a deeper integration of SwiftPM here: >>> >>> - What if Xcode will introduce two new types of groups (the folder color >>> could be orange like Swift for example, or even contain the bird icon). >>> - These groups are analogous to already existing group types except they’ll >>> represent Swift modules / packages >>> - Basically we’ll have a single project file with multiple modules, where >>> these modules should only exist inside that project (this is my own need >>> right now) >>> - Such a package / module group will have a configurable utilities, where >>> one could configure the modules >>> - This will reduce the re-building process, allow us to keep everything >>> (not only .a or we’ll be able to hide .a files and just keep the >>> sourcefiles inside such groups) inside a single project, gain the shiny >>> namespaces like above, and make the file management way easier >>> - This also should allow us create cross-dependencies if there is a good >>> need for that in our project >>> >>> + MainProject >>> | >>> +—Reference (module) > > [The entire original message is not included.] > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
