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.

-----Original Message-----
From: "Adrian Zubarev via swift-evolution" <swift-evolution@swift.org>
Sent: ‎20/‎05/‎2016 09:16 AM
To: "swift-evolution@swift.org" <swift-evolution@swift.org>
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 (daniel_dun...@apple.com) 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 
<swift-build-...@swift.org> 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


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)
<div style="font-family: Helvetica, Arial; font-size: 

[The entire original message is not included.]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to