3 ms·
But if you consider “liar” to be an object, > liar.hats.every((hat) => hat.color === "green") will throw a TypeError: Cannot read properties of undefined. Th
by chiakic 2y ago
But if you consider “liar” to be an object,
> liar.hats.every((hat) => hat.color === "green")
will throw a TypeError: Cannot read properties of undefined.
That’s definitely not `true`.
- wrigby 2y agoThis depends on `liar.hats` being undefined, but what if `liar.hats` is an empty array? That seems like an equally valid way of representing a person that owns no hats.
- deleted 2y ago[deleted]
- ecshafer 2y agoYou implemented the problem wrong, and thus got an error. If hats is a list of colors, then every hat != green is true if the list is empty.
- LudwigNagasena 2y agoI wouldn’t say it is wrong per se. It certainly defies the conventional translation into FOL, but there is no a priori reason to pick the conventional formalism of FOL for this problem.
- Volundr 2y agoI don't think that's true. What if the liar buys a red hat? liar.hats.push("red") This only works if hats is an empty array. If hats is just not a property people have (undefined in the example), then you can't represent adding them. Now you might argue hats can be null when a user doesn't have them, or a non-empty array, but that's clearly not a great way to represent that. Now you have owning no hats represented two different ways as an empty array or null, and must build special casing around the null case (unless you are using a language where nil and the empty array are one and the same)
- recursive 2y agoHm. No. const liar = { hats: [] }; liar.hats.every(hat => hat.color === "green") true