2 ms·
While this is true, this kind of flexibility makes the other layers harder. On the database side, if you use a relational store, it forces you to normal form 5
by alexvoda 6y ago
While this is true, this kind of flexibility makes the other layers harder.
On the database side, if you use a relational store, it forces you to normal form 5 which few people are used to.
On the front end, allowing everywhere an arbitrary number elements instead of mandatory one, means you need custom widgets everywhere. You need a way of marking the default one. Validation also gets exponentially more complicated.
On the UX side, people are simply not used to this level of flexibility. It will get labeled as impenetrable.
As much as I like the idea, and believe it is elegant, most probably YAGNI.
- BoorishBears 6y agoI know this is just a throwaway example, but feel just looking at the code layer this kind of elegance is comes at the cost of clarity and conveying intent, and I see that happen a lot. The second method explicitly checking for null is great because it's telling me so many things very plainly: 1. There can be no address for a user 2. There is otherwise one address per one user 3. If there is no address we explicitly do nothing (if clause with no else) If we do the same analysis for the first method it actually feels like it's conveying false conclusions. It's implying there's multiple addresses per user, for example. And the fact that if a user has no address we don't do anything is still true, but the intent feels buried in the behavior of the loop. By default I try to value writing code in a way that conveys the most intent possible over how it feels to write For example, another language with nullable types (Kotlin) has user.address()?.let { it.sendMail() } I've seen people write code like this, and it just feels so unnecessary, how much longer does it take to parse? And it still doesn't have the clarity of intent that a simple null check has.