Allow getting non-enumerable properties

[stroncium]

Changes the way to check property for enumerability, fixes #46

[stroncium]

Side note: no code changes around enumerability were ever applied to anything but get.

[sindresorhus]

I need your opinion; does it really make sense to check enumerability at all? I just read through the original issue about it (#23) and I'm not sure I buy the argument anymore. Also, it's weird that the check is only applied to get and not the other methods.

[stroncium]

Con: it really does work different from normal object access(obviously ignoring whole exception vs undefined part there). But I can hardly imagine real world situations when people want to read properties flagged non-enumerable using this lib, and if they do their design will clearly considered by most to be really bad.

Pro: it actually seems to better match expectations and frequent use-cases. This bug is about inherited properties and it makes sense it should read inherited properties. For the other cases, it silently protects from sometimes hard to trace bugs.

All in all, I'd say I'm for doing enumerability checks.

Logic should probably be applied to all methods, yeah. (Though logic will always be weirdly different between reading and modifying methods for prototypes.)

[stevemao]

I vote for removing related code of enumerability.

[stroncium]

@sindresorhus So, what are we going for there? Removal of enumerability checks or unifying method behavior?

[lselden]

@sindresorhus Request to get this merged, though I understand it might qualify as a major release bump. I don't see any reason that a value's enumerable value should matter if someone explicitly tries to access it using .get / .has

[sindresorhus]

Remove the enumerability checks.

[stroncium]

Side note, I feel like this package could use a bit more tests. Nothing exact of the top of my head, but I can't believe existing ones cover all the tricky stuff.

[sindresorhus]

@stroncium Comment in #70 if you have any ideas of what the tests might be.