> On Apr 6, 2017, at 1:15 PM, Michael J LeHew Jr <[email protected]> wrote:
>
>
>> On Apr 6, 2017, at 10:37 AM, Douglas Gregor via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On Apr 6, 2017, at 10:28 AM, Ricardo Parada <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Do you think in the future it might be possible to convert to strings?
>>>
>>> For example, I am imagining a CoreData-like framework on the server (where
>>> there is no Objective-C), where I would like to get the type of the root
>>> object and keys forming the path. That way I can go to an object model,
>>> get the corresponding entity, and traversed relationships, and destination
>>> attribute. All that information (table name, table joins for the
>>> relationships traversed, column names, etc.) would then be used to
>>> construct the SQL.
>>
>> Key-paths could be extended to allow introspection of the components along
>> the path, in which case you would be able to map between key paths into your
>> specific data model and the tables/columns in your database. This is not the
>
> ... ? You left us hanging there Doug! :)
Eh, sorry! Making key-paths Codable could definitely make sense in the future,
as you note. But I don’t know that a “blessed String representation” makes
sense for key-paths.
>
> We do mention in the proposal that support for marshalling to external
> representation (String, Codable should that be accepted, etc) would highly
> desirable in the future, for IB / CoreData type scenarios and more. It is
> one of the principle reasons we decided not to allow key paths to compose
> with transformations (functions and closures), as while that is very powerful
> and interesting, once you go there you're not really a key path any more.
>
> It's not part of this initial proposal, but could easily be brought up as a
> follow-on in the future.
Right.
- Doug
>
>>
>> - Doug
>>
>>>
>>>
>>>
>>>> On Apr 6, 2017, at 12:37 PM, Douglas Gregor <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>>>
>>>>> On Apr 6, 2017, at 9:31 AM, Sean Heber <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>>
>>>>>> On Apr 6, 2017, at 11:19 AM, Douglas Gregor <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution
>>>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>
>>>>>>> I agree, there's an analogy between strings and key paths, and in that
>>>>>>> regards the single quote would make sense. I would not complain.
>>>>>>
>>>>>> The only analogy between strings and key-paths is that the existing
>>>>>> Cocoa APIs for key-paths use strings. That’s not an analogy to hang
>>>>>> language syntax on, because it’s relevance will fade quickly.
>>>>>
>>>>> Why would it fade quickly? Do we expect the concept of keypaths to go
>>>>> away over time? If so, why are we even designing a syntax for keypaths?
>>>>
>>>> The link between key-paths and strings will go away over time. The *only*
>>>> reason anyone associates strings with keypaths is because Cocoa’s current
>>>> key-paths are string-based. This proposal makes any string representation
>>>> of key-paths an implementation detail that could be used for
>>>> interoperability with Cocoa’s current system. There is no reason for a
>>>> type-unsafe string representation to ever be in the user model.
>>>>
>>>>
>>>>>> The core team discussed single quotes, and decided that we want to save
>>>>>> them for something in the string/character realm.
>>>>>
>>>>> Are they to be saved for something specific or is this just because a lot
>>>>> of languages use single quotes for character literals? Why is this
>>>>> association any more sacred than an association with Cocoa string
>>>>> keypaths?
>>>>
>>>>
>>>> Lots of languages use single quotes for character literals; we may want to
>>>> bring them back for it.
>>>>
>>>> - Doug
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
