Hacker News Reader

Hacker News

Comment by meddlepal | Hacker News Reader

Parent Full thread

meddlepal

I think the reaction has been more to Kotlin than Scala.

View on HN

Arguably, Kotlin took some of the better ideas from Scala.

Arguably? I'd say it's rather obvious, but overall they're different languages with different goals.

To be fair, “arguably” has come to mean “no doubt.”

You are thinking about "unarguably". ;)

No, I was talking about the now usual in the English-speaking practice amplification of its meaning as "can be supported or shown by persuasive argument", e.g., That is arguably the best book on the subject.

https://www.thefreedictionary.com/arguably

I’m more a Scala dev than Kotlin

Think it’s safe to say both influenced Java’s Record, shoulda mentioned Kotlin too.

Kotlins data class is functionally basically the same as a lombok @Data class used in Java. Why Java didn't keep the name "Data class" I don't know.

"Data" is such an overloaded and vague term, anyway. Almost all classes have "data", so what the heck is a "data class"? Is it one that only has data (not behavior)? Nope- these can have arbitrary methods.

So, I'm kind of glad they didn't use it. (But, to clarify, I really don't care what color the bike shed is)

I'm more wondering why they didn't go with "struct" or "value class", especially because the latter is exactly what we've been calling "class whose equals() is defined by content rather than identity" for many years.

Because while in the end project valhalla will not call them value classes, it is a sort of an overloaded term.

Structs/value types can be mutable, records are not. They are basically tuples with names. And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.

> Structs/value types can be mutable, records are not.

Fair point about record fields not being reassignable (not the same as immutable for others reading this).

> And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.

Well, sure. All non-primitives are passed by reference. That doesn't stop them from being referred to as value types.

But in light of your first point, I agree that choosing a totally new term probably makes sense.

I stand corrected, shallowly immutable or as you note fields not being reassignable it is.

Reply on news.ycombinator.com