> On Jun 9, 2016, at 3:27 AM, Jordan Rose via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Hi, Paulo. Thanks for bringing this up; it’s definitely an interesting
> problem to solve.
>
> My thoughts are mostly in line with yours, that disambiguation at the call
> site is the most Swift-like thing to do, at least as a first step. Maybe we
> can add some way to record general preferences, or maybe just asking people
> to define a wrapper function to put the disambiguation in one place is fine.
>
> I’m not particularly a fan of the “from” syntax or the “@“ syntax, but I
> don’t have anything better. (And the “not a fan” is entirely a taste thing,
> plus a general desire not to steal new keywords or operator characters.
> Neither of these are blockers.) I’ve been playing with silly things like this:
>
> str.(ModuleA.capitalized)()
>
Seeing all these proposals that people make, it makes me thinks that extensions
as they exist are not fully understood... People seem to consider them like
the Xtext/Xtend/c# extension METHODS, which means that maybe they should also
be added to Swift, and people would not be confused:
public static func capitalized(self:String)() {}
Then these would be easily individually imported from module x,y or z with the
current syntax, and then "extension String {}" would retain it current scoping
behavior
No matter what, I think many extensions are just a bad outlook on OOD, but
properly understood, they are great.
> which I think has come up on-thread already. (It’s close to Paul’s '::',
> anyway.)
>
> A bonus is if we can use this same thing for globals. We have a problem today
> where “Foo.Bar” can’t refer to a member of a module if there’s also a type
> named “Foo”; changing the syntax to “Foo::Bar” or “Bar from Foo” (or adding
> it as an alternative) would solve that problem and provide consistency.
>
> Sorry I don’t have anything too conclusive to add. My last point is that
> while we do have a problem today, it’s a problem we’ve lived with for two
> years, and any features we add to solve it are additive. That means it’s okay
> if we don’t come up with an answer in Swift 3.
>
> Jordan
>
>
>> On Jun 6, 2016, at 06:47, Paulo Faria via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> Actually I don’t like the prioritization of the modules import. I’m much
>> more in favor of disambiguating at call site. like we have to do in any
>> other case of ambiguity in Swift. The concept of precedence is only present
>> in operators and that makes sense because it’s in their nature. I think #4
>> or #5 or any other way to disambiguate at call site would be the most
>> appropriate.
>>
>>
>>
>>> On Jun 4, 2016, at 10:29 PM, Paulo Faria <pa...@zewo.io> wrote:
>>>
>>> Hello, everyone.
>>>
>>> I want to discuss the problem of name ambiguity when a computed property or
>>> function is defined with the same name and type in different modules.
>>> Currently there’s no way to disambiguate the implementation in use cases
>>> similar to the one contained in the gist below.
>>>
>>> https://gist.github.com/paulofaria/f48d0b847a0fb7c125d163d0e349500a
>>>
>>> The gist also contains some informal proposals. The idea is to create a
>>> formal proposal based on the discussion that shall follow.
>>>
>>> Cheers,
>>> Paulo
>>
>> _______________________________________________
>> 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
