> > On 20 Mar 2017, at 12:12, 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. >
Then let me add a +1 for the verbose solution as well. Sometimes verbosity is not bad. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl >> 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
