Loud and clear! :-) 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 <[email protected]> wrote: > >> >> On Mar 30, 2017, at 2:03 PM, Louis D'hauwe via swift-evolution >> <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
