> Le 19 mars 2017 à 16:41, Ricardo Parada via swift-evolution
> <swift-evolution@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@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@friends[0].name
>> luke@path
>>
>> or other with help of community.
>> _______________________________________________
>> 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
