[swift-evolution] Static Dispatch Pitfalls

Sun May 22 14:02:44 CDT 2016

Regards
(From mobile)

> On May 22, 2016, at 8:03 PM, Goffredo Marocchi <panajev at gmail.com> wrote:
> 
> Sent from my iPhone
> 
>> On 22 May 2016, at 18:36, L. Mihalkovic via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On May 22, 2016, at 5:31 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>>> On May 22, 2016, at 8:39 AM, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
>>>> 
>>>> 
>>>>> On May 22, 2016, at 3:15 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Sent from my iPad
>>>>> 
>>>>>>> On May 22, 2016, at 1:49 AM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>>> 
>>>>>>> On 22.05.2016 3:01, L. Mihalkovic via swift-evolution wrote:
>>>>>>> Read the proposal... I have an aversion to-go coffee cups that remind
>>>>>>> people that hot coffee may burn them, and when my daughter was 4 we
>>>>>>> explained to her why knives were to be handled with care, rather than
>>>>>>> remove them all from her sight. IMHO the proposal evoques mandating
>>>>>>> training wheels rather than letting people learn naturally from their
>>>>>>> errors.
>>>>>> 
>>>>>> I can partially support this opinion. But we have a situation with protocol extension methods and static dispatches in which we need Swift's help on compilation stage. IMO Using your words, right now we just got knife in our hands *without* any explanation. Then we hurt ourselves, and *then* we know that such methods will be dispatched statically(and the rule of dispatch is quite non-obvious). This is another extreme like "remove all knives". We need some golden middle. Personally I believe the solution is in compiler warning and in some method to 'fix' this warning.
>>>>> 
>>>>> Why not just make it an error and require an annotation on the extension methods?
>>>> 
>>>> See   https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018560.html
>>>> And   https://github.com/lmihalkovic/swift-lang/tree/master/Dispatching.playground
>>> 
>>> That doesn't answer my question.  I don't like any of the suggestions you posted.  I think we should just leave the behavior as is (at least for now) and just require annotations on non-default methods in protocol extensions (making it an error to declare a non-default method without the annotation).
>> 
>> Considering how things work fine the way they are today once THEIR logic is understood (the only problem today seems to be one of expectations mismatch, not that something is broken or illogic), it would IMHO be a waste of energy to revisit only to end up with a system that would only support a single model. It something is done, it might as well be to add freedom.
> 
> It is logical because by definition it is not a random behaviour and it works as it is not marred by bugs and yes you can make it work (variable amount of pain depending how big he code base is and how many people work on it), but the problem of expectations mismatch and a bit steep learning curve (and probability of submarine errors popping up to haunt future self) is not one that should be swept under the rug.
> 
> Part of the problem comes from the desire to put code in protocols/interfaces. Java went full steam ahead with it in Java 8 and Swift did so later on, but I still feel it creates quite a bit of problems, maybe more than it solves. Sure, it is giving life to a new magical paradigm, but all magic comes with a price ;). I may be too defensive about this change,  but I would love to read a very very convincing arguments as to why I would want anything more than methods (or properties maybe, but they are methods too ;)) in a protocol/interface. I thought the point was that behaviour and implementation ought to be decoupled :).
> 

Whatch Dave's presentation at WWDC on protocol based programming, if he does not convince you, then perhaps nobody will. IMHO the ship of why POP has long sailed... Objc is great, and was extremely innovative 30 years ago. Today there is a team of increadibly talented people bringing a new logic to the table, and if anyone is capable of making it work wonderfully for the next 30 years of apple dev, it is them. Our job is to act like sounding boards for where they want to go, not try to stop them or bring everything back to what they have set out to replace.

If you still have questions about methods in protocols, lookup presentations from brian goetz on the topic, or consider how it is a veeery elegant idiomatic swift solution for the problem of optional protocol methods in objc 

> 
> One could bends things a bit and say that following a relatively strict TDD approach with genuine unit tests (everything is a mock but the class under test and Apple's own classes perhaps), integration, and automation tests that Objective-C's opt-in strictness (hello -Weverything, lightweight generics, nullability annotations, and various annotations like instancetype, NS_REQUIRES_SUPER, NS_DESIGNATED_INITIALIZER, etc...) is more than a safe enough path that gives you the most freedom and runtime responsibility to be used wisely and productively. Cocoa is a wonderful API to write apps with and yes it is not very Swift like and linked to the Objective-C runtime also in style, but perhaps that says something NCOs about both languages. In Objective-C having message sending/dynamic polymorphism by default never introduced illogical or hard to work through behaviour.

It would be a shame with llvm under the hood to have every single method call resolved against a 13,000 entry hash table today. Ask bertrand serlet what he might have given to have llvm at his disposal when he was working on that part of the runtime.

> 
>> 
>> So if you make it optional to have an attribute (I seem to recall chris explicitely saying that annotations were not the idiomatic swift way to convey these types of behavirial adjustments) on non required extension methods, then what you describe is basically one of the proposals I listed.. for a simple reason mind you... what I listed is what I saw people debate. A few options were left out as being too complex to summarize, or not ringing true to what exists today and what has been explained about protocols with great clarity by Dave on stage at WWDC. Interestingly enough, the idea of default methods on the protocol itself (which I like in java8) was already listed by him and at least someone else in the compiler team.
>> 
>> Coming from working in asm, c, c++, perl, tcl, vb, java, c#, js, objc, scala, typescript and go in that order, I can get used to anything as long as its logic seems reasonable and adequately explained.  After reading so many emails I thought I might not be the only one craving a simple one page summary of what had been said so far.
>> 
>> 
>>> 
>>>> 
>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution