`propOr`/`pathOr` inconsistency

propOr('bar', 'foo')({ foo: undefined }); // -> undefined
pathOr('bar', ['foo'])({ a: undefined });  // -> 'bar'

Both propOr and pathOr define themselves as returning the value if it is non-null; else the ‘or’ value. These two functions should consistently handle undefined

[zachlysobey]

Not sure if I should piggy-back on this or open a new issue. I get that it behaves the way the docs say it does, but I am not convinced that this is the right approach.

To restate the issue:

propOr returns the default if it fails a hasOwnValue check, but pathOr returns the default if the path lookup returns a falsy value null, undefined, or NaN. (thanks for the correction @Bradcomp)

I find this to be confusing and inconsistent.

const foo = { bar: null }
R.propOr('hello', 'bar', foo) // null
R.pathOr('hello', ['bar'], foo) // 'hello'

The similarity in the fn names would make you think intuitively that they behave the same way.

Personally, I think I prefer the way this is handled in R.pathOr because it seems more intuitive. Its like using R.path(...) OR (||) the default.

R.path(['bar'], foo) || 'hello' // 'hello'

(Note: its not immediately clear to me how/if this relates to https://github.com/ramda/ramda/issues/1712, apologies if this is a dupe)

[CrossEye]

@nfantone: I’m going to try very hard to get a release out this weekend. That should be part of it.