3 ms·
>val emily1 = Person("Emily", "Maness", 25) The assumption of inputs based on the order of the class items frightens me!
by mrlala 7y ago
>val emily1 = Person("Emily", "Maness", 25)
The assumption of inputs based on the order of the class items frightens me!
- lmm 7y agoYou can use named parameters if you're worried: val emily1 = Person(firstName="Emily", lastName="Maness", age=25) Scala's approach to constructors is a good example of convention over configuration; in Java 99.9% of classes have a constructor like: this.firstName = firstName; this.lastName = lastName; this.age = age; which is just ceremonial boilerplate that obscures the actual logic of what the class is doing (an IDE can generate the constructor for you, but the person maintaining your code still has to take the time to comprehend it). You can do the more complicated things in cases where you need to, but it's important to keep the simple case simple.
- nine_k 7y agoLombok solves this for Java.
- Vax45 7y agoI would try out Immutables before Lombok. It generates code using the standard annotation processor instead of modifying OpenJDK's AST tree.
- lmm 7y agoUsing Lombok ends up being just as much effort as using a different JVM language, and the rewards are smaller.
- nine_k 7y agoThe learning curve is way less steep, and you can introduce it into an existing project with zero impedance mismatch.
- neuronic 7y agoYes, but in teams where there is no hope of switching to another JVM language like Kotlin, Lombok can reduce boilerplate by enormous amounts. It's a compromise.
- nickik 7y agoLombok is really not that complex and it not close to using a different language.