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 <[email protected]> > 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 >> <[email protected]> wrote: >> >> 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 > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
