> On Mar 20, 2017, at 4:12 AM, David Hart via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>
>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> +1. This is my favorite solution so far.
>>
>> With ‘Person.keypath.name' it is obvious that we are creating a key path.
>> There is no ambiguity for the reader. With autocomplete it will be very
>> little extra typing anyway…
>
> But that adds a lot of verbosity. They disregarded #keyPath because it was
> too verbose.
For what it's worth, I'm not especially worried about verbosity. Long-term I'm
hoping that this feature and the ones we build on it will see far broader use
than keypaths ever did in ObjC, but a little more typing isn't that bad. What
*is* a loss though, is something I'll call "conceptual surface area".
We talk a lot about "conceptual load" when designing APIs, which is the notion
that even if each individual concept is simple, the sheer volume of things that
you have to keep track of can be exhausting, make learning difficult, and cause
mistakes. With some features though, the conceptual load comes more from what
isn't there. With unbound methods, you have to know "ok String.init gets me
String's initializer as an unbound function I can call, so I can do stuff like
[1, 2, 3].map(String.init)" but you *also* have to know "but that doesn't work
on subscripts or properties, just methods". So even though there's only one
concept here, the hole in the feature is itself an additional concept; an
irregularly shaped thing having more mental surface area.
So the biggest reason I like the current syntax proposal is that it fills in a
hole, reducing the conceptual surface area to "ok, Foo.bar gets me an unbound
version of anything".
Unfortunately, as everyone has pointed out, static/class properties make that
claim not so true. Hanging keypaths off a ".keypath" class property also
conflicts, since there's nothing stopping a method or property from being
called "keypath". I see several paths forward from here, not least of which is
"it's probably not a huge deal in practice", but I'd like to think about it and
listen to the discussion a bit longer before suggesting anything.
David
>
>> Thanks,
>> Jon
>>
>>> On Mar 19, 2017, at 9:20 PM, Dietmar Planitzer via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>> Key paths of this form:
>>>
>>> Person.name
>>>
>>> will always make it harder than necessary to:
>>>
>>> * search for all places where we are using key paths
>>>
>>> * do efficient code completion. Eg you’ll get a mix of static properties
>>> and key paths
>>>
>>>
>>> We’ve been using this kind of setup in our projects for some time now:
>>>
>>> class Person {
>>>
>>> struct keypath {
>>>
>>> static let name = #keyPath(Person.name)
>>> …
>>> }
>>>
>>> …
>>> }
>>>
>>> where a keypath is then used like this:
>>>
>>> Person.keypath.name
>>>
>>> and this has worked very well. It makes it easy to see where we are using a
>>> keypath rather than accessing some static property, it works very nicely
>>> with code completion and it makes it very easy to search for all places
>>> where we are using key paths from the Person type.
>>>
>>> I would prefer that the proposed keypath model would automatically organize
>>> key paths like this.
>>>
>>>
>>> Regards,
>>>
>>> Dietmar Planitzer
>>>
>>>
>>>> On Mar 19, 2017, at 20:49, Matthew Johnson via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>>
>>>>
>>>> Sent from my iPad
>>>>
>>>>> On Mar 19, 2017, at 10:31 PM, Jaden Geller via swift-evolution
>>>>> <swift-evolution@swift.org> wrote:
>>>>>
>>>>> I think the clarity desired is more similar to that obtained by the `try`
>>>>> keyword. Ya, the compiler knows that this function throws already, but
>>>>> Swift aims for clarity in the source code. Clarity is often achieved by
>>>>> providing potentially redundant information for the programmer.
>>>>>
>>>>> As proposed, it is difficult to distinguish a key path from a static
>>>>> variable. Maybe that's not problematic? Well, it's up to the community to
>>>>> decide.
>>>>
>>>> Why don't we just say all instance properties are shadowed by a static
>>>> constant property of the same name with the appropriate key path type.
>>>> This makes it not mysterious at all but instead very straightforward. We
>>>> could even say that static and class properties are shadowed by a key path
>>>> property on the meta type.
>>>>
>>>>
>>>>> I do think it is a bit worrisome that static variable access might cause
>>>>> side effects (or at least, might take a while to compute) but creating
>>>>> key paths should not, but that's a fringe case probably.
>>>>>
>>>>> On Mar 19, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution
>>>>> <swift-evolution@swift.org> wrote:
>>>>>
>>>>>>> On Mar 19, 2017, at 4:47 PM, Charles Srstka <cocoa...@charlessoft.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This is true of many things. It is why IDEs make type information
>>>>>>>> readily available.
>>>>>>>
>>>>>>> Is clarity not a thing to be desired?
>>>>>>
>>>>>> Clarity is in the eye of the beholder. Here's one notion of clarity:
>>>>>>
>>>>>> sum :: (Num a, Foldable t) => t a -> a
>>>>>> sum = foldl (+) 0
>>>>>>
>>>>>> Here's another:
>>>>>>
>>>>>> int sum(int array[], size_t len) {
>>>>>> int total = 0;
>>>>>> for(size_t i = 0; i < len; i++) {
>>>>>> total += array[i];
>>>>>> }
>>>>>> return total;
>>>>>> }
>>>>>>
>>>>>> And another:
>>>>>>
>>>>>> SUM PROC
>>>>>> ; this procedure will calculate the sum of an array
>>>>>> ; input : SI=offset address of the array
>>>>>> ; : BX=size of the array
>>>>>> ; output : AX=sum of the array
>>>>>>
>>>>>> PUSH CX ; push CX onto the STACK
>>>>>> PUSH DX ; push DX onto the STACK
>>>>>>
>>>>>> XOR AX, AX ; clear AX
>>>>>> XOR DX, DX ; clear DX
>>>>>> MOV CX, BX ; set CX=BX
>>>>>>
>>>>>> @SUM: ; loop label
>>>>>> MOV DL, [SI] ; set DL=[SI]
>>>>>> ADD AX, DX ; set AX=AX+DX
>>>>>> INC SI ; set SI=SI+1
>>>>>> LOOP @SUM ; jump to label @SUM while CX!=0
>>>>>>
>>>>>> POP DX ; pop a value from STACK into DX
>>>>>> POP CX ; pop a value from STACK into CX
>>>>>>
>>>>>> RET ; return control to the calling
>>>>>> procedure
>>>>>> SUM ENDP
>>>>>>
>>>>>>
>>>>>> And one more:
>>>>>>
>>>>>> extension Sequence where Element: Arithmetic {
>>>>>> func sum() {
>>>>>> return reduce(0, +)
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Clarity is not achieved by explicitly stating every detail of your code.
>>>>>> It's achieved by explicitly stating what needs to be said, and *not*
>>>>>> explicitly stating what *doesn't* need to be said.
>>>>>>
>>>>>> The people who oppose using a special syntax for this feature think
>>>>>> that, by and large, clarity is best served by *not* explicitly stating
>>>>>> when you're using a key path. They believe that you are unlikely to run
>>>>>> into ambiguity and, when you do, it will be easy to work around it. This
>>>>>> is an opinion, so it's open to disagreement, but that's where they stand
>>>>>> on it.
>>>>>>
>>>>>> --
>>>>>> Brent Royal-Gordon
>>>>>> Architechies
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>
>> _______________________________________________
>> 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
