> Am 07.06.2016 um 22:27 schrieb L Mihalkovic <[email protected]>:
>
>>
>> On Jun 7, 2016, at 9:47 PM, Thorsten Seitz <[email protected]
>> <mailto:[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).
So it is dependent on the order of the imports? That’s rather fragile IMO and I
would prefer having to solve clashes explicitly independent of import order,
e.g. by having to hide the version from Lib1:
import Lib1 hiding func2 // strawman syntax
import func Lib2.func2
-Thorsten
>
>
>>>
>>> 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
