ramda Standardize prop or and path or functionality to match documentation

Follow up to #2888 Reverts change to propOr that caused issue in test suite

Mar 09 '20 15:03 Tworley96

It all goes the wrong way. Adding nth support to prop/path causes unnecessary complexity. And it's very inefficient...

Mar 22 '20 15:03 ku8ar

@ku8ar:

Do you have suggestions? I think the main constraints are that things like path(foo) and path([foo]) should always have the same behavior, and that all of these, but especially the simplest ones like path should be as performant as possible.

Mar 23 '20 01:03 CrossEye

@CrossEye Yes of course. I added a suggestion here: https://github.com/ramda/ramda/issues/2974#issuecomment-602273378 That suggestion will simplify this code. In short: remove nth from prop and path. But this is a hard decision, considering that there is already version 0.27 with this feature...

Mar 23 '20 07:03 ku8ar

I have absolutely no problem changing the behavior back in the next version if it turns our we made a mistake. I don't have much time now to investigate why this was added, and we need to do that before deciding whether it's worth the costs it adds.

Mar 23 '20 20:03 CrossEye