Isn’t there a third way? I wrote a bridge between Swift and Java without having
to
change the compiler at all by using a code generator to generate bridging Swift
rather than having a Java importer. The script introspects the classes/packages
you’re interested in using a script and generates code such as the following:
/// public java.lang.String java.lang.Object.toString()
private static var toString_MethodID_9: jmethodID?
open func toString() -> String! {
var __locals = [jobject]()
var __args = [jvalue]( repeating: jvalue(), count: 1 )
let __return = JNIMethod.CallObjectMethod( object: javaObject,
methodName: "toString", methodSig: "()Ljava/lang/String;", methodCache:
&JavaObject.toString_MethodID_9, args: &__args, locals: &__locals )
defer { JNI.DeleteLocalRef( __return ) }
return __return != nil ? String( javaObject: __return ) : nil
}
This bridging code, along with some supporting classes is compiled
conventionally
along with your app. See:
https://github.com/SwiftJava/SwiftJava <https://github.com/SwiftJava/SwiftJava>
https://github.com/SwiftJava/java_swift/blob/master/Sources/JavaObject.swift
<https://github.com/SwiftJava/java_swift/blob/3a48760a5528ccb31d998afbfcb09d291268674f/Sources/JavaObject.swift>
https://github.com/SwiftJava/SwiftJava/blob/master/src/genswift.java
<https://github.com/SwiftJava/SwiftJava/blob/master/src/genswift.java>
Python’s introspection seems to be reasonably capable and could certainly
support
this approach. You’d need some sort of omni-type enum for the arguments and
return.
https://stackoverflow.com/questions/196960/can-you-list-the-keyword-arguments-a-python-function-receives
<https://stackoverflow.com/questions/196960/can-you-list-the-keyword-arguments-a-python-function-receives>
https://docs.python.org/2/c-api/intro.html
<https://docs.python.org/2/c-api/intro.html>
John
> On 11 Nov 2017, at 16:13, David Hart via swift-evolution
> <[email protected]> wrote:
>
>
> On 11 Nov 2017, at 16:02, Joe Groff via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>>
>>
>> On Nov 10, 2017, at 8:35 PM, Chris Lattner via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>>
>>>> On Nov 10, 2017, at 6:12 PM, Slava Pestov via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>>
>>>>
>>>>> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution
>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>
>>>>> Setting this aside, I’m very curious to hear whether type providers
>>>>> influence your thinking after you’ve had a chance to look into them. I
>>>>> have always thought they were very cool.
>>>>
>>>> I’m in favor of solving this problem with something like type providers
>>>> also. The required compiler changes would be significant but would also
>>>> clean up the interface between the ClangImporter, Sema and Serialization.
>>>> If done right it would be a net gain that would benefit all users, instead
>>>> of just adding YetAnotherCornerCase™ that makes implementation maintainers
>>>> curse and scream.
>>>
>>> I find it ironic that you’re talking pejoratively about a feature that has
>>> very narrow impact, complaining about how much of an impact on the compiler
>>> it would have, and then pine for a hugely invasive feature - one that would
>>> cause a ton of code churn, and probably wouldn’t actually be enough to
>>> eliminate the special cases in place because of ObjC interop.
>>
>> You underestimate the impact this would have on function call type checking,
>> but since this is an additive, non-ABI-stability feature, I have trouble
>> considering it a candidate for Swift 5, so I don't think there's a time
>> constraint forcing us to consider the "narrow" vs "huge" dimension. What's
>> the best thing for the language and tools in the long term? This is a
>> feature that influences the semantics of potentially any call site in all
>> Swift code, which we'd have to live with forever if we accepted it now.
>> Opening up the compiler architecture to make custom importers easier to
>> write is a great solution to a ton of problems, including yours I think,
>> without adding complexity to the core language. Experience in .NET land
>> seems to show it's a great technique for integrating dynamic systems with
>> static type systems, without poking unnecessary holes in the static
>> language's type system
>
> I agree with Joe. I also think that it would be very important to compare
> both approaches in detail before choosing one, because the last thing we want
> is to end up with both in the language. And if this proposal is accepted, we
> might refrain from introducing custom importers later, even if they are the
> better long term solution.
>
> I want Swift to continue to shine for a very long time because I enjoy this
> language and I just want to make sure we don’t jeopardize that by choosing a
> quick solution without taking in consideration other solutions.
>
>> -Joe
>>
>>> -Chris
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
