[swift-evolution] Smart KeyPaths

[Ricardo Parada]

I was thinking that maybe it could be an error or warning to have a static property with the same name as a normal property. But I'm simply thinking out loud a possible solution to this ambiguity problem without introducing a symbol for key paths. Just trying to see if we can keep it simple. 

I'm not arguing in favor of this though. Im just trying to bring up possible solutions so we that we can better compare the alternatives and understand the pros and cons of each. 

By the way I do like the colon notation that you and others have suggested. I hope we pick the best at the end. 

I'm excited about this proposal and want it to be the successful. One of the most exciting things happening in swift right now IMHO. 


> On Mar 19, 2017, at 3:51 PM, Jean-Daniel <mailing at xenonium.com> wrote:
> 
> 
>> Le 19 mars 2017 à 16:41, Ricardo Parada via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> I agree that they can get mixed up with static properties. However, I think I would not mind because it would only cause an ambiguity when having a static property with the same name as the property which would be an odd practice I think.  
> 
> I disagree. How the reader is supposed to now there is a static property or not ? Having readable code is more important than having easy to write code.
> 
> Without context, the following statement is ambiguous, This ambiguity can easily be avoid by choosing an other syntax. So why would we want to introduce it in the first place ?
> 
> let name = Person:friends[0].name
> 
> 
> 
>> I was defining static properties with the same name as the property in order to smart key paths.  For example:
>> 
>> Class Person {
>>    static firstName: KeyPath<String>(“firstName”)
>>    static lastName: KeyPath<String>(“lastName”)
>> 
>>    var firstName: String 
>>    var lastName: String
>> 
>>    …
>> }
>> 
>> 
>> So that I could create qualifiers, ie. Person.firstName.like(“R*”), and sort orderings, Person.firstName.asc().
>> 
>> I think with these smart key paths the need for these static properties that mirror the property on the instance would not be required.
>> 
>> 
>> 
>> 
>>> On Mar 17, 2017, at 2:27 PM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> On 17.03.2017 20:04, Michael LeHew via swift-evolution wrote:
>>>> Hi friendly swift-evolution folks,
>>>> 
>>>> The Foundation and Swift team  would like for you to consider the following
>>>> proposal:
>>>> 
>>>> Many thanks,
>>>> -Michael
>>>> 
>>>> 
>>>> Smart KeyPaths: Better Key-Value Coding for Swift
>>>> ...
>>> 
>>> Just my 2 cents. FWIW, I feel like the proposed syntax is VERY confusing.
>>> 
>>> Person.friends[0].name - like access to static property. T.method can't have subscript for it and then some field. So, I believe such key paths deserve its own syntax.
>>> 
>>> luke[path] - very close to access the subscript of instance. In compare to T.method, we can call result of T.method(i.e. let m = T.method; m()), just like the T.method itself(foo.method()). But here we are calling some kind of subscript instead of access property by "path".
>>> 
>>> There is no some 'special' marker for me that saying "hey, there is references to properties used" from the first look.
>>> 
>>> Probably we can consider another separators, like
>>> 
>>> Person:friends[0].name
>>> luke:path
>>> 
>>> Person->friends[0].name
>>> luke->path
>>> 
>>> Person[friends[0].name] // single brackets for type
>>> luke[[path]] // double brackets for instance
>>> 
>>> Person at friends[0].name
>>> luke at path
>>> 
>>> or other with help of community.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>