> Am 09.06.2016 um 07:55 schrieb L. Mihalkovic <[email protected]>:
>
>
>
> On Jun 8, 2016, at 9:02 PM, Thorsten Seitz <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>>> Am 07.06.2016 um 22:27 schrieb L Mihalkovic <[email protected]
>>> <mailto:[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?
>
> Swift is a c-ish derivative-ish... intentionally.
>
>
>> 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
>
> Interesting...
>
>
> Or
>
> Import func Lib2.func2 as func2FromLib2
Yes. Hiding and renaming would be great to have when importing.
-Thorsten
>
>> -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
