Leaving the "should we do it at all" question aside…
> On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>
> We propose introducing this protocol to the standard library:
>
> protocol DynamicCallable {
> associatedtype DynamicCallableArgument
> associatedtype DynamicCallableResult
>
> func dynamicCall(arguments: [(String, DynamicCallableArgument)]) throws ->
> DynamicCallableResult
> }
>
> It also extends the language such that function call syntax - when applied to
> a value of DynamicCallable type - is accepted and transformed into a call to
> the dynamicCall member. The dynamicCall method takes a list of tuples: the
> first element is the keyword label (or an empty string if absent) and the
> second value is the formal parameter specified at the call site.
I don't really like passing the argument names to the parameter list. Instead,
I would prefer to see them handled in the member-resolution method. You don't
give a design for DynamicMemberLookupProtocol here, but assuming that you're
imagining that a call like this:
foreignObject.someValue(keyword1: 42, "foo", keyword2: 19)
Would translate to something like this:
foreignObject.dynamicMethodLookup(name:
"someValue").dynamicCall(arguments: [("keyword1", 42), ("", "foo"),
("keyword2", 19)])
I would instead like it to look like this:
foreignObject.dynamicMethodLookup(name: "someValue", arguments:
["keyword1", "", "keyword2"]).dynamicCall(arguments: [42, "foo", 19])
This would better suit languages like Squeak (or Swift!) where you cannot fully
look up a method without its keywords. (Languages like Python would simply
store the keywords inside the object returned by `dynamicMethodLookup`.) It
would also allow you to use our "get-a-closure" syntax:
let uncalledMethod = foreignObject.someValue(keyword1:_:keyword2:)
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
