The lack of namespaces is leading people astray


#1

The lack of namespaces is making people create all kinds of "design patterns".

struct API { static let endpoint = "http://example.com/api"}
Here is an "improvement" to the above "design pattern" to prevent instantiating API:
struct API { private init() {} static let endpoint = "http://example.com/api"}
Finally, here is another "improvement" that uses enum instead of struct to avoid having to write the private initializer:
enum API { static let endpoint = "http://example.com/api"}
I doubt any of you find this beautiful. Yet these "design patterns" (just hacks IMO) are spreading like the plague because of the lack of namespaces.
What do you think?


(Adrian Zubarev) #2

If I remember correctly it has been said that we don't need namespaces in favor of submodules, which schould solve these issues.

···

--
Adrian Zubarev
Sent with Airmail

Am 30. Januar 2017 um 14:55:31, Tuur Anton via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

The lack of namespaces is making people create all kinds of "design patterns".

struct API {
static let endpoint = "http://example.com/api"
}

Here is an "improvement" to the above "design pattern" to prevent instantiating API:

struct API {
private init() {}
static let endpoint = "http://example.com/api"
}

Finally, here is another "improvement" that uses enum instead of struct to avoid having to write the private initializer:

enum API {
static let endpoint = "http://example.com/api"
}

I doubt any of you find this beautiful. Yet these "design patterns" (just hacks IMO) are spreading like the plague because of the lack of namespaces.

What do you think?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Russ Bishop) #3

I’ve used languages with namespaces for many years. I don’t find multi-level namespaces to be much of an improvement over a single-level namespace in most cases. On the contrary, I find it much simpler to avoid hunting around importing a hundred namespaces. This is what you end up with:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Web;
using System.Text;
using System.Data;
using System.Data.SqlClient;
using System.Web;
using System.Net <http://system.net/>;
using System.Net <http://system.net/>.HttpClient;

The only thing we really need in Swift is the ability to have a Private submodule, especially for mixed-mode frameworks.

Russ

···

On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution <swift-evolution@swift.org> wrote:

The lack of namespaces is making people create all kinds of "design patterns".

What do you think?


(David Sweeris) #4

Personally, I’m in favor of namespaces, but it’s more of a “seems like a good idea” thing than “I need this because <reason>”, at least from my PoV. I’m inclined to just defer to the core team’s judgement on this one.

On the plus side though, if we ever do get formal namespaces, it should be relatively simple to search for enums with no cases and give a fixit.

- Dave Sweeris

···

On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution <swift-evolution@swift.org> wrote:

The lack of namespaces is making people create all kinds of "design patterns".

struct API {
    static let endpoint = "http://example.com/api"
}

Here is an "improvement" to the above "design pattern" to prevent instantiating API:

struct API {
    private init() {}
    static let endpoint = "http://example.com/api"
}

Finally, here is another "improvement" that uses enum instead of struct to avoid having to write the private initializer:

enum API {
    static let endpoint = "http://example.com/api"
}

I doubt any of you find this beautiful. Yet these "design patterns" (just hacks IMO) are spreading like the plague because of the lack of namespaces.

What do you think?


(Robert Widmann) #5

I submitted a proposal with TJ a while ago that tried to address this comprehensively because the trouble is if you just want submodules you have to define how our current penta-scheme of access control interacts with each level or do away with a few of them to make some simplifying assumptions. It also raises an ambiguity with qualified imports that has to be worked out.

···

On Jan 30, 2017, at 9:00 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

If I remember correctly it has been said that we don't need namespaces in favor of submodules, which schould solve these issues.

--
Adrian Zubarev
Sent with Airmail
Am 30. Januar 2017 um 14:55:31, Tuur Anton via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

The lack of namespaces is making people create all kinds of "design patterns".

struct API {
    static let endpoint = "http://example.com/api"
}

Here is an "improvement" to the above "design pattern" to prevent instantiating API:

struct API {
    private init() {}
    static let endpoint = "http://example.com/api"
}

Finally, here is another "improvement" that uses enum instead of struct to avoid having to write the private initializer:

enum API {
    static let endpoint = "http://example.com/api"
}

I doubt any of you find this beautiful. Yet these "design patterns" (just hacks IMO) are spreading like the plague because of the lack of namespaces.

What do you think?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Pranshu Goyal) #6

+1

···

On 31 January 2017 at 11:32, Russ Bishop via swift-evolution < swift-evolution@swift.org> wrote:

On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution < > swift-evolution@swift.org> wrote:

The lack of namespaces is making people create all kinds of "design
patterns".

What do you think?

I’ve used languages with namespaces for many years. I don’t find
multi-level namespaces to be much of an improvement over a single-level
namespace in most cases. On the contrary, I find it much simpler to avoid
hunting around importing a hundred namespaces. This is what you end up with:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Web;
using System.Text;
using System.Data;
using System.Data.SqlClient;
using System.Web;
using System.Net;
using System.Net.HttpClient;

The only thing we really need in Swift is the ability to have a Private
submodule, especially for mixed-mode frameworks.

Russ

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
*Pranshu Goyal*
*iOS Developer*
*tlkn*


(Rien) #7

I have been known to mimic namespaces as well, however now that SPM is here, I no longer see a need for it.

Still, I won’t object to it.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl

···

On 01 Feb 2017, at 06:30, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution <swift-evolution@swift.org> wrote:

The lack of namespaces is making people create all kinds of "design patterns".

struct API {
    static let endpoint = "http://example.com/api"
}

Here is an "improvement" to the above "design pattern" to prevent instantiating API:

struct API {
    private init() {}
    static let endpoint = "http://example.com/api"
}

Finally, here is another "improvement" that uses enum instead of struct to avoid having to write the private initializer:

enum API {
    static let endpoint = "http://example.com/api"
}

I doubt any of you find this beautiful. Yet these "design patterns" (just hacks IMO) are spreading like the plague because of the lack of namespaces.

What do you think?

Personally, I’m in favor of namespaces, but it’s more of a “seems like a good idea” thing than “I need this because <reason>”, at least from my PoV. I’m inclined to just defer to the core team’s judgement on this one.

On the plus side though, if we ever do get formal namespaces, it should be relatively simple to search for enums with no cases and give a fixit.

- Dave Sweeris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Derrick Ho) #8

If you make a dynamic framework called APIFramework
And add a public class called URL_ME

You can instantiate it with APIFramework.URL_ME() from your project.

I haven't tried to see if this would work with global variables but I
assume it would.

···

On Mon, Jan 30, 2017 at 3:09 PM Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote:

I submitted a proposal with TJ a while ago that tried to address this
comprehensively because the trouble is if you just want submodules you have
to define how our current penta-scheme of access control interacts with
each level or do away with a few of them to make some simplifying
assumptions. It also raises an ambiguity with qualified imports that has
to be worked out.

On Jan 30, 2017, at 9:00 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

If I remember correctly it has been said that we don't need namespaces in
favor of submodules, which schould solve these issues.

--
Adrian Zubarev
Sent with Airmail

Am 30. Januar 2017 um 14:55:31, Tuur Anton via swift-evolution (
swift-evolution@swift.org) schrieb:

The lack of namespaces is making people create all kinds of "design
patterns".

struct API {
    static let endpoint = "http://example.com/api"
}

Here is an "improvement" to the above "design pattern" to prevent
instantiating API:

struct API {
    private init() {}
    static let endpoint = "http://example.com/api"
}

Finally, here is another "improvement" that uses enum instead of struct to
avoid having to write the private initializer:

enum API {
    static let endpoint = "http://example.com/api"
}

I doubt any of you find this beautiful. Yet these "design patterns" (just
hacks IMO) are spreading like the plague because of the lack of namespaces.

What do you think?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Step C) #9

I remain a fan of adding 'namespace' to the language.

In the meantime I'll continue using the enum static member approach. But I would love to have something semantically cleaner.

···

El ene. 30, 2017, a las 3:09 PM, Robert Widmann via swift-evolution <swift-evolution@swift.org> escribió:

I submitted a proposal with TJ a while ago that tried to address this comprehensively because the trouble is if you just want submodules you have to define how our current penta-scheme of access control interacts with each level or do away with a few of them to make some simplifying assumptions. It also raises an ambiguity with qualified imports that has to be worked out.

On Jan 30, 2017, at 9:00 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

If I remember correctly it has been said that we don't need namespaces in favor of submodules, which schould solve these issues.

--
Adrian Zubarev
Sent with Airmail
Am 30. Januar 2017 um 14:55:31, Tuur Anton via swift-evolution (swift-evolution@swift.org) schrieb:

The lack of namespaces is making people create all kinds of "design patterns".

struct API {
    static let endpoint = "http://example.com/api"
}

Here is an "improvement" to the above "design pattern" to prevent instantiating API:

struct API {
    private init() {}
    static let endpoint = "http://example.com/api"
}

Finally, here is another "improvement" that uses enum instead of struct to avoid having to write the private initializer:

enum API {
    static let endpoint = "http://example.com/api"
}

I doubt any of you find this beautiful. Yet these "design patterns" (just hacks IMO) are spreading like the plague because of the lack of namespaces.

What do you think?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution