BTW, Java via JNI would be another good application of this proposal. I once used a JNI wrapper library in C++ and it was pretty hairy and tedious.
I think we might want to declare a "Python object" as implementing swift protocols. If the methods that implement a protocol are NOT implemented in Swift, then the python code should be called -- the names already match. Otherwise the developer the has to map the protocol methods and properties to the Python methods, etc. C. Keith Ray https://leanpub.com/wepntk <- buy my book? http://agilesolutionspace.blogspot.com/ twitter: @ckeithray http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf On Dec 4, 2017, at 7:30 PM, Chris Lattner <clatt...@nondot.org> wrote: >>> On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> The first one, has no static type info, no compile time checking, it's not >>> self documenting, no type inference so people will be forced to use a >>> dynamic reference at the call site to store the result, leading to more >>> type loss, and all this spirals down. >>> I'm already starting to fear dynamic. >>> Edit: The danger has passed (Phew!) ... and dynamic wasn't been abused >>> after all, no need to down vote me after 3 years :) >> >> From what I can gather, `dynamic` is used when declaring types, but there's >> no indication at call sites that what is being invoked is dynamic. And it >> even allows for casting basically anything to the `dynamic` type. >> >> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/dynamic >> >> So here we have a language community that was (is?) very vocal about caution >> when it comes to type inference with `var`, but seems to have accepted the >> validity of `dynamic`. This seems to show that at least one community has >> absorbed this sort of change (arguably a more "dangerous" version than what >> is being proposed here) with no real issues. > > Right. dynamic in C# is far broader (and more “dangerous”) than what I’m > proposing. That said, because there have been absolutely zero specific > examples of the sorts of harm DynamicMemberLookup could cause, it is > difficult to speculate about exactly which boogieman people are afraid of. > >> So I have a few questions: >> >> - Would it be enough to require annotation of the dynamic nature of a type >> at the declaration sites, if that still means the call sites aren't >> explicitly annotated? > > It is impossible to solve a problem if it cannot be explained in enough > detail to provide examples. Personally, I don’t see the problem at all. > >> - Why do some think the Swift community would be more at risk of abuse of >> this feature than the C# community seems to have been? > > > People are making bizarre claims about what the spirit of Swift is, informing > me of things which are obviously not true, and ignoring the evidence I > present to them. This is doubly humorous given that I have a fairly good > sense for the design balance and tradeoffs of existing features in Swift > today, along with detailed rationale for why they were added, when, and all > of the discussion that backed them. I chalk this up to the fear of the > unknown or perhaps a mistrust for the peers these people work with. > > My goal is to make the design and proposal writeup as good as possible, and > the fear mongering about abuse has led me to add several options for further > narrowing the potential for abuse, including to the point of requiring every > new adoptee to go through the Swift evolution process for review. During the > review period for DynamicMemberLookup, people who carry these concerns are > welcome to +1 one or more of those. > > I personally am far more interested in getting to the bottom of Doug’s > concerns - it isn’t clear to me what exactly his preferred direction actually > is, but that discussion is based on engineering tradeoffs and may well lead > to a change to the proposal or a complete change in direction. > > -Chris >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
