Re: [swift-evolution] The lack of namespaces is leading people astray

[Rien via swift-evolution]

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 
>  wrote:
> 
> 
>> On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution 
>>  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 ”, 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

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

Re: [swift-evolution] The lack of namespaces is leading people astray

[David Sweeris via swift-evolution]

> On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution 
>  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 ”, 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

Re: [swift-evolution] The lack of namespaces is leading people astray

[Step Christopher via swift-evolution]

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 
>  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 
>>  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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] The lack of namespaces is leading people astray

[Pranshu Goyal via swift-evolution]

+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*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] The lack of namespaces is leading people astray

[Russ Bishop via swift-evolution]

> On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution 
>  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

Re: [swift-evolution] The lack of namespaces is leading people astray

[Derrick Ho via swift-evolution]

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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] The lack of namespaces is leading people astray

[Robert Widmann via swift-evolution]

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 
>  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

Re: [swift-evolution] The lack of namespaces is leading people astray

[Adrian Zubarev via swift-evolution]

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

[swift-evolution] The lack of namespaces is leading people astray

[Tuur Anton via swift-evolution]

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