> On Jun 9, 2016, at 8:14 PM, Jordan Rose <[email protected]> wrote:
>
>>
>> On Jun 9, 2016, at 11:12, L Mihalkovic <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>> On Jun 9, 2016, at 8:01 PM, Thorsten Seitz <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>>
>>>> Am 09.06.2016 um 19:46 schrieb L Mihalkovic via swift-evolution
>>>> <[email protected] <mailto:[email protected]>>:
>>>>
>>>>>
>>>>> On Jun 9, 2016, at 7:04 PM, Jordan Rose <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>>>
>>>>>> On Jun 9, 2016, at 07:35, L. Mihalkovic <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>>
>>>>>> On Jun 9, 2016, at 3:27 AM, Jordan Rose via swift-evolution
>>>>>> <[email protected] <mailto:[email protected]>> 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.
>>>>>
>>>>> I’m not sure what you mean. How does changing the declaration site solve
>>>>> the disambiguation problem at the call site? (And how do you think Swift
>>>>> extensions differ from C# extensions?)
>>>>>
>>>>
>>>> sorry, I thought the example was clearer than it actually is (pb with
>>>> writing thgs in a train)
>>>>
>>>>
>>>> This is code I wrote a couple weeks ago (parsing some WWDC related things
>>>> in C#):
>>>> namespace HtmlAgilityPackPlus {
>>>> using HtmlAgilityPack;
>>>>
>>>> public static class Extender {
>>>> public static HtmlNode ChildOfType(this HtmlNode node, string
>>>> name) {
>>>> var n = node.ChildNodes.Where( x => x.Name == name).First();
>>>> return n;
>>>> }
>>>> public static HtmlNode FirstLink(this HtmlNode node) {
>>>> var child = node.ChildOfType("a");
>>>> return child;
>>>> }
>>>> public static HtmlNode FirstDescendantMatching(this HtmlNode node,
>>>> Func<HtmlNode, bool> predicate) {
>>>> var seq = node.Descendants().Where( x => predicate(x) );
>>>> return ((seq?.Count() ?? 0) > 0) ? seq.First() : null;
>>>> }
>>>> }
>>>> }
>>>>
>>>> XText and XTend work the same (I think at some point so did kotlin, but I
>>>> haven’t checked since the final)
>>>>
>>>>
>>>> Now this is some Swift code (yes I am not bothering with the details)
>>>> module A ===
>>>>
>>>> extension String {
>>>> func oneA() { }
>>>> func twoA() { }
>>>> func threeA() { }
>>>> }
>>>>
>>>>
>>>> module B ===
>>>>
>>>> extension String {
>>>> func oneB() { }
>>>> func twoB() { }
>>>> func threeB() { }
>>>> }
>>>>
>>>> We could say that the Swift extension is a ‘batch’ oriented mechanism:
>>>> first a target type is decided by forming a scope
>>>> then many extension methods can be added together
>>>> Of course one can also add a single method at a time in as many single
>>>> scopes. But the fact remains.. the syntax is oriented towards
>>>> anonymity of the source
>>>> batch adds
>>>>
>>>> as you can see, this is not how C# works.
>>>>
>>>> So now, given that context, I was suggesting that people seem to consider
>>>> Swift extensions as something they currently are NOT: there is no way to
>>>> pinpoint a particular extension in a particular module (import the module,
>>>> inherit its extensions), there is NO way to target a given method in a
>>>> given extension in a given module.
>>>>
>>>>
>>>> My point was to suggest that it may show that current extensions are
>>>> invaluable for something like the adapter pattern (than you E. Gamma), but
>>>> not entirely suited for the more fine-grained scenario that people keep
>>>> use in the mail thread.
>>>>
>>>> This led to my proposal to ALSO support (not REPLACE)
>>>>
>>>> module A ===
>>>> extension String {
>>>> func oneA() { }
>>>> func twoA() { }
>>>> func threeA() { }
>>>> }
>>>> // more like the GO syntax
>>>> public static func
>>>> indexOfSubStringInReversedOrder(self:String)(pattern:String) -> Int {}
>>>>
>>>>
>>>> module B ===
>>>> extension String {
>>>> func oneB() { }
>>>> func twoB() { }
>>>> func threeB() { }
>>>> }
>>>> // more like the c#/XText/XTend/... syntax
>>>> public static func indexOfSubStringInReversedOrder(self:String,
>>>> pattern:String) -> Int {}
>>>>
>>>> because we can now do the following without altering anything
>>>>
>>>> import func moduleA.indexOfSubStringInReversedOrder
>>>> var idx = "blahblahXYZblah".indexOfSubStringInReversedOrder("zyx")
>>>> _______________________________________________
>>>
>>>
>>> What hinders me in the case of Swift’s extensions to write
>>>
>>> import func moduleA.String.oneB
>>>
>>> This would achieve just the same thing.
>>>
>>
>> hmmm….. I know… tempting, right?! but how then does this not DESTROY the
>> other behavior?! “compiler, be smart… if I say nothing, then let the
>> runtime loader import everything everywhere because it is still very useful
>> even if I don’t want to recognize it right now. But then if I start to
>> import something, then tell the runtime loader that he has to stop mocking
>> about with all these extension blocks to String that he will find and just
>> add the one method that I care about. and btw, remember to the other thing
>> in all my other source files” I look forward to read the source code that
>> will make it work, because I know I do not have the beginning of the
>> imagination required to have a clue how it will look like.
>
> I'm really not sure what you're talking about. Extension methods are resolved
> at compile-time, not run-time. (Except @objc extension methods, which are as
> dangerous as categories ever were, and which isn't changing.)
>
this is wonderful news… all this time I was under the impression that
module MyApp {
source1.swift
import moduleA
var str = “sdfa”.extensionMethod()
source2.swift
import moduleB
var str = “sdfa”.extensionMethod()
}
was a problem… but it is not, because under the hood the definition of String
changes depending on which source file I am looking at. The problem only occurs
when both modules are imported in the same source file. I guess I never ran
into it because I only use extensions as adapters.
thx.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
