> On Jun 7, 2016, at 9:47 PM, Thorsten Seitz <[email protected]> wrote:
>
>
>
> Am 07.06.2016 um 20:11 schrieb L Mihalkovic via swift-evolution
> <[email protected] <mailto:[email protected]>>:
>
>> T1 =======
>> import Lib1
>> var str = func2() // lib1
>>
>> T2 =======
>> import Lib1
>> import func Lib2.func2
>> var str = func2() // lib2
>
> Shouldn't func2() be ambiguous here? It is imported from Lib1 and from Lib2.
>
> -Thorsten
no, that is precisely the point .. it works!! I am able to override whatever
my laziness brought into scope from Lib1 (caused by my * import) with a
meticulously chosen implementation from Lib2. It is brilliant. extensions on
the other hand work differently (although something could undoubtedly be done
about them, I cannot entirely convince myself that it is time well spent. It
would be if that could be a stepping stone form something else (which I have
not been able to identify so far).
>>
>> T3 =======
>> import Lib1
>> import func Lib2.func2
>> var str = “str”.allCaps() // ERROR : ambiguous name
>>
>>
>> Lib1 ===========
>> public func func2() -> String {
>> return "lib1"
>> }
>> // only during T3
>> public extension String {
>> public func allCaps() -> String {
>> return “lib1_"
>> }
>> }
>>
>> Lib2 ===========
>> public func func2() -> String {
>> return "lib2"
>> }
>> // only during T3
>> public extension String {
>> public func allCaps() -> String {
>> return "lib2_"
>> }
>> }
>>
>>
>> T3 shows how differently extensions are treated from all other
>> exportable/importable artifacts: extensions are NOT sensitive to the scope
>> of imports. they are fully loaded as soon as the loader detects that the
>> module is referenced (they come from their own table inside the module
>> binary).
>>
>>
>>
>>
>>> On Jun 7, 2016, at 6:45 PM, Paul Cantrell <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>>
>>>> On Jun 7, 2016, at 11:36 AM, Paul Cantrell via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>>>
>>>>> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution
>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>
>>>>> On Jun 7, 2016, at 4:53 PM, Tony Allevato <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>>> I like the "from" keyword the best, but I'll take my own stab at a
>>>>>> modification:
>>>>>>
>>>>>> import ModuleA
>>>>>> import ModuleB
>>>>>>
>>>>>> "hello world".(capitalized from ModuleA)()
>>>>>> "hello world".(capitalized from ModuleB)()
>>>>>> "hello world".(someProperty from ModuleA)
>>>>>> "hello world".(someProperty from ModuleB)
>>>>>
>>>>> Hmmm... looks like an oxymoron in its own right... I was under the
>>>>> impression so far that the point of extensions was that they are not tied
>>>>> to a source. This brings us back full circle to the very definition of
>>>>> extensions... However you slice it, swift is lacking some scoping bellow
>>>>> modules, and/or arround some of the language features.
>>>>
>>>> IIRC, a member of the core team (Joe Groff, maybe?) indicated several
>>>> months ago on the list that methods are internally namespaced to their
>>>> module. Alas, I can’t find that message. It was a long time ago.
>>>
>>> Ah, here it is:
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000928.html
>>>
>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000928.html>
>>>
>>> Joe Groff wrote:
>>>
>>> “It's helpful to think of method names as being namespaced in Swift, by
>>> both their enclosing module and type. If two modules independently extend a
>>> protocol with a method of the same name, you still semantically have two
>>> distinct methods that dispatch independently. The extension would have to
>>> be factored into a common module both modules see for them to interact.”
>>>
>>> IOW, yes, Swift internally does something very much like "hello
>>> world”.ModuleA::capitalized().
>>>
>>>> You can see this in the fact that two different files can see two
>>>> different extension methods:
>>>>
>>>> A.swift
>>>>
>>>> import ModuleA
>>>> …
>>>> "hello world".capitalized()
>>>>
>>>> B.swift
>>>>
>>>> import ModuleB
>>>> …
>>>> "hello world".capitalized()
>>>>
>>>> …even if they end up compiled into the same binary. And that makes sense:
>>>> A.swift only expected to see ModuleA’s extension, and was presumably coded
>>>> around that expectation. That ModuleB happened to end up mixed into the
>>>> same binary shouldn’t change the behavior of A.swift
>>>>
>>>> If my understand is correct, then my "hello world”.ModuleA::capitalized()
>>>> and your "hello world".(capitalized from ModuleA)() are both just syntax
>>>> to expose something that Swift already tracks internally.
>>>>
>>>> Cheers, P
>>>>
>>>> _______________________________________________
>>>> 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] <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
