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