> On Jun 8, 2016, at 9:02 PM, Thorsten Seitz <tseit...@icloud.com> wrote:
>
>
>>> Am 07.06.2016 um 22:27 schrieb L Mihalkovic <laurent.mihalko...@gmail.com>:
>>>
>>>
>>> On Jun 7, 2016, at 9:47 PM, Thorsten Seitz <tseit...@icloud.com> wrote:
>>>
>>>
>>>
>>> Am 07.06.2016 um 20:11 schrieb L Mihalkovic via swift-evolution
>>> <swift-evolution@swift.org>:
>>>
>>>> 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
> -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 <cantr...@pobox.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On Jun 7, 2016, at 11:36 AM, Paul Cantrell via swift-evolution
>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution
>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>
>>>>>>>> On Jun 7, 2016, at 4:53 PM, Tony Allevato <allev...@google.com> 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
>>>>>
>>>>> 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
>>>>>> swift-evolution@swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
