> On Nov 11, 2017, at 9:44 AM, John Holdsworth <m...@johnholdsworth.com> wrote:
>
> 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.
Good point. For unidirectional importing without deep support for overriding or
runtime integration like what we do with ObjC, which AIUI is the extent of
Chris's ambition with Python interfacing here, a code generator can get the job
done without requiring deep compiler integration, though at the expense of
needing an added tool in your build process. Have you looked at all into making
SwiftJava integrate with the package manager or with Xcode yet? How's that
experience?
-Joe
> 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/java_swift/blob/master/Sources/JavaObject.swift
> 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://docs.python.org/2/c-api/intro.html
>
> John
>
>> On 11 Nov 2017, at 16:13, David Hart via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>
>> On 11 Nov 2017, at 16:02, Joe Groff via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>>
>>>
>>>> On Nov 10, 2017, at 8:35 PM, Chris Lattner via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>>
>>>>>> On Nov 10, 2017, at 6:12 PM, Slava Pestov via swift-evolution
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution
>>>>>> <swift-evolution@swift.org> 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
>>>> 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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
