Remove prefixes from all Apple frameworks


(Louis D'hauwe) #1

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

    import UIKit

    class FooViewController: UIViewController {
  
    }

Dropping the prefix would simply lead to the following:

    import UIKit

    class FooViewController: ViewController {
  
    }

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

    import UIKit

    class FooViewController: UIKit.ViewController {
  
    }

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

    import UI

    class FooViewController: UI.ViewController {
  
    }

This all seems to me like a natural continuation of SE-0086 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0086-drop-foundation-ns.md>.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe


(Joe Groff) #2

The teams at Apple own how their APIs get reflected in Swift. This is outside the scope of swift-evolution.

-Joe

···

On Mar 30, 2017, at 2:03 PM, Louis D'hauwe via swift-evolution <swift-evolution@swift.org> wrote:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

    import UIKit

    class FooViewController: UIViewController {
  
    }

Dropping the prefix would simply lead to the following:

    import UIKit

    class FooViewController: ViewController {
  
    }

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

    import UIKit

    class FooViewController: UIKit.ViewController {
  
    }

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

    import UI

    class FooViewController: UI.ViewController {
  
    }

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.


(Karl) #3

+ Int.max

- Karl


(Adrian Zubarev) #4

The issue is, this has nothing to do with swift evolution. You could file a bug report for the Apple frameworks, but I doubt something this huge will make it through.

···

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution (swift-evolution@swift.org) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

import UIKit

class FooViewController: UIViewController \{

\}

Dropping the prefix would simply lead to the following:

import UIKit

class FooViewController: ViewController \{

\}

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

import UIKit

class FooViewController: UIKit\.ViewController \{

\}

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

import UI

class FooViewController: UI\.ViewController \{

\}

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

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


(Louis D'hauwe) #5

Loud and clear! :slight_smile:
I am, however, very interested in the thoughts of the Swift evolution community for this idea.

– Louis D'hauwe

···

On 30 Mar 2017, at 23:28, Joe Groff <jgroff@apple.com> wrote:

On Mar 30, 2017, at 2:03 PM, Louis D'hauwe via swift-evolution <swift-evolution@swift.org> wrote:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

   import UIKit

   class FooViewController: UIViewController {
  
   }

Dropping the prefix would simply lead to the following:

   import UIKit

   class FooViewController: ViewController {
  
   }

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

   import UIKit

   class FooViewController: UIKit.ViewController {
  
   }

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

   import UI

   class FooViewController: UI.ViewController {
  
   }

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

The teams at Apple own how their APIs get reflected in Swift. This is outside the scope of swift-evolution.

-Joe


(Karl) #6

Oh yeah; and they might want to reserve unprefixed names for native Swift interfaces, similar to what happened to Foundation.

Maybe they already did. We’ll have to wait until WWDC for the next major version of the SDKs.

- Karl

···

On 30 Mar 2017, at 23:07, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

The issue is, this has nothing to do with swift evolution. You could file a bug report for the Apple frameworks, but I doubt something this huge will make it through.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

    import UIKit

    class FooViewController: UIViewController {

    }

Dropping the prefix would simply lead to the following:

    import UIKit

    class FooViewController: ViewController {

    }

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

    import UIKit

    class FooViewController: UIKit.ViewController {

    }

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

    import UI

    class FooViewController: UI.ViewController {

    }

This all seems to me like a natural continuation of SE-0086 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0086-drop-foundation-ns.md>.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

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

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


(Louis D'hauwe) #7

I disagree, my proposal is not to rename Apple frameworks.
It is to improve the importing of Objective-C designed frameworks to remove the unnecessary prefixes.

– Louis D'hauwe

···

On 30 Mar 2017, at 23:07, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

The issue is, this has nothing to do with swift evolution. You could file a bug report for the Apple frameworks, but I doubt something this huge will make it through.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

    import UIKit

    class FooViewController: UIViewController {

    }

Dropping the prefix would simply lead to the following:

    import UIKit

    class FooViewController: ViewController {

    }

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

    import UIKit

    class FooViewController: UIKit.ViewController {

    }

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

    import UI

    class FooViewController: UI.ViewController {

    }

This all seems to me like a natural continuation of SE-0086 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0086-drop-foundation-ns.md>.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

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


(Rien) #8

The problem with unprefixed names is name clashes with my own code.
Not often, but often enough. Then you have to invent your owm prefixes.
Besides, NS… and UI… make it much, MUCH more convenient to google…

Regards,
Rien

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

···

On 30 Mar 2017, at 23:42, Louis D'hauwe via swift-evolution <swift-evolution@swift.org> wrote:

Loud and clear! :slight_smile:
I am, however, very interested in the thoughts of the Swift evolution community for this idea.

– Louis D'hauwe

On 30 Mar 2017, at 23:28, Joe Groff <jgroff@apple.com> wrote:

On Mar 30, 2017, at 2:03 PM, Louis D'hauwe via swift-evolution <swift-evolution@swift.org> wrote:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

   import UIKit

   class FooViewController: UIViewController {
  
   }

Dropping the prefix would simply lead to the following:

   import UIKit

   class FooViewController: ViewController {
  
   }

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

   import UIKit

   class FooViewController: UIKit.ViewController {
  
   }

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

   import UI

   class FooViewController: UI.ViewController {
  
   }

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

The teams at Apple own how their APIs get reflected in Swift. This is outside the scope of swift-evolution.

-Joe

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


(Adrian Zubarev) #9

Something like a type- and type-alias when importing from Obj-C to Swift?

That would be reasonable, I’d guess.

···

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:12:30, Louis D'hauwe (louisdhauwe@silverfox.be) schrieb:

I disagree, my proposal is not to rename Apple frameworks.
It is to improve the importing of Objective-C designed frameworks to remove the unnecessary prefixes.

– Louis D'hauwe

On 30 Mar 2017, at 23:07, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

The issue is, this has nothing to do with swift evolution. You could file a bug report for the Apple frameworks, but I doubt something this huge will make it through.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution (swift-evolution@swift.org) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

import UIKit

class FooViewController: UIViewController \{

\}

Dropping the prefix would simply lead to the following:

import UIKit

class FooViewController: ViewController \{

\}

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

import UIKit

class FooViewController: UIKit\.ViewController \{

\}

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

import UI

class FooViewController: UI\.ViewController \{

\}

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

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


(Jean-Daniel) #10

Not only with your own code. There is so many Apple Framework, I’m pretty sure it won’t be difficult to find conflicting class name.

···

Le 31 mars 2017 à 08:02, Rien via swift-evolution <swift-evolution@swift.org> a écrit :

The problem with unprefixed names is name clashes with my own code.
Not often, but often enough. Then you have to invent your owm prefixes.
Besides, NS… and UI… make it much, MUCH more convenient to google…

Regards,
Rien

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

On 30 Mar 2017, at 23:42, Louis D'hauwe via swift-evolution <swift-evolution@swift.org> wrote:

Loud and clear! :slight_smile:
I am, however, very interested in the thoughts of the Swift evolution community for this idea.

– Louis D'hauwe

On 30 Mar 2017, at 23:28, Joe Groff <jgroff@apple.com> wrote:

On Mar 30, 2017, at 2:03 PM, Louis D'hauwe via swift-evolution <swift-evolution@swift.org> wrote:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

  import UIKit

  class FooViewController: UIViewController {
  
  }

Dropping the prefix would simply lead to the following:

  import UIKit

  class FooViewController: ViewController {
  
  }

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

  import UIKit

  class FooViewController: UIKit.ViewController {
  
  }

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

  import UI

  class FooViewController: UI.ViewController {
  
  }

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

The teams at Apple own how their APIs get reflected in Swift. This is outside the scope of swift-evolution.

-Joe

_______________________________________________
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


(Adrian Zubarev) #11

Typo: I actually meant type- and module-alias.

···

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:16:14, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

Something like a type- and type-alias when importing from Obj-C to Swift?

That would be reasonable, I’d guess.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:12:30, Louis D'hauwe (louisdhauwe@silverfox.be) schrieb:

I disagree, my proposal is not to rename Apple frameworks.
It is to improve the importing of Objective-C designed frameworks to remove the unnecessary prefixes.

– Louis D'hauwe

On 30 Mar 2017, at 23:07, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

The issue is, this has nothing to do with swift evolution. You could file a bug report for the Apple frameworks, but I doubt something this huge will make it through.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution (swift-evolution@swift.org) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

import UIKit

class FooViewController: UIViewController \{

\}

Dropping the prefix would simply lead to the following:

import UIKit

class FooViewController: ViewController \{

\}

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

import UIKit

class FooViewController: UIKit\.ViewController \{

\}

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

import UI

class FooViewController: UI\.ViewController \{

\}

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

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


(Louis D'hauwe) #12

Aliases would be one step towards my vision, but long term I'd like to see a class like "UIViewController" to be imported as "ViewController".

···

On 30 Mar 2017, at 23:17, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Typo: I actually meant type- and module-alias.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:16:14, Adrian Zubarev (adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>) schrieb:

Something like a type- and type-alias when importing from Obj-C to Swift?

That would be reasonable, I’d guess.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:12:30, Louis D'hauwe (louisdhauwe@silverfox.be <mailto:louisdhauwe@silverfox.be>) schrieb:

I disagree, my proposal is not to rename Apple frameworks.
It is to improve the importing of Objective-C designed frameworks to remove the unnecessary prefixes.

– Louis D'hauwe

On 30 Mar 2017, at 23:07, Adrian Zubarev <adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>> wrote:

The issue is, this has nothing to do with swift evolution. You could file a bug report for the Apple frameworks, but I doubt something this huge will make it through.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

    import UIKit

    class FooViewController: UIViewController {

    }

Dropping the prefix would simply lead to the following:

    import UIKit

    class FooViewController: ViewController {

    }

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

    import UIKit

    class FooViewController: UIKit.ViewController {

    }

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

    import UI

    class FooViewController: UI.ViewController {

    }

This all seems to me like a natural continuation of SE-0086 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0086-drop-foundation-ns.md>.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

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


(Adrian Zubarev) #13

By an alias what I really meant was some kind of a macro like NS_SWIFT_NAME for types and the module name.

···

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:19:51, Louis D'hauwe (louisdhauwe@silverfox.be) schrieb:

Aliases would be one step towards my vision, but long term I'd like to see a class like "UIViewController" to be imported as "ViewController".

On 30 Mar 2017, at 23:17, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Typo: I actually meant type- and module-alias.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:16:14, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

Something like a type- and type-alias when importing from Obj-C to Swift?

That would be reasonable, I’d guess.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:12:30, Louis D'hauwe (louisdhauwe@silverfox.be) schrieb:

I disagree, my proposal is not to rename Apple frameworks.
It is to improve the importing of Objective-C designed frameworks to remove the unnecessary prefixes.

– Louis D'hauwe

On 30 Mar 2017, at 23:07, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

The issue is, this has nothing to do with swift evolution. You could file a bug report for the Apple frameworks, but I doubt something this huge will make it through.

--
Adrian Zubarev
Sent with Airmail

Am 30. März 2017 um 23:03:52, Louis D'hauwe via swift-evolution (swift-evolution@swift.org) schrieb:

Apple frameworks contain prefixes, carried over from Objective-C.
These exist to prevent class and method name collisions.

Mattt Thompson has a great article about this, containing the following brilliant excerpt:
"Namespacing is the preeminent bugbear of Objective-C. A cosmetic quirk with global implications, the language’s lack of identifier containers remains a source of prodigious quantities of caremad for armchair language critics." (http://nshipster.com/namespacing/)

Since Swift can handle with these naming conflicts, wouldn't it make sense to drop all framework prefixes in a Swift environment?

A classic example is UIKit, where all classes are prefixed with "UI".
Code example:

import UIKit

class FooViewController: UIViewController \{

\}

Dropping the prefix would simply lead to the following:

import UIKit

class FooViewController: ViewController \{

\}

Since conflicts need to be handled by specifying the module name, the following could be used if "ViewController" was also used by either some, other than UIKit, imported framework or by a user defined class:

import UIKit

class FooViewController: UIKit\.ViewController \{

\}

"UIKit.ViewController" is of course quite longer than the current "UIViewController".
An improvement could be to allow frameworks to specify an abbreviated form.
UIKit could define "UI" as its abbreviation, making the following code valid:

import UI

class FooViewController: UI\.ViewController \{

\}

This all seems to me like a natural continuation of SE-0086.
I do realise this would be a major change, breaking pretty much every Swift iOS, macOS, tvOS and watchOS project.
But in the long term, I think it's worth it.

– Louis D'hauwe

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