[ryanseys]

> However there is one caveat. If some of the data members are of a mutable class, Data does no additional immutability enforcement.

Seems like an area of concern / gotchas. Either restrict Data to not allow mutable nested objects, or provide immutable versions of stdlib object types as well and enforce that those types are used.

Yet another Rubocop-that-should-just-be-built-into-the-language coming in 3...2...1...

[lolinder]

This is pretty common when adding immutability to a language that wasn't designed around it. Whether it's JavaScript's `const` or Java's `final`, languages almost always add shallow immutability rather than deep. My sense is that it's quite difficult to add deep immutability in later.

Rust is the main exception I'm aware of, and it had deep immutability from the get-go.

[danmur]

Scala has immutable types in the standard library too, but I don't think they make much sense without the language being statically typed. By which I mean adding immutable types to Python or whatever's stdlib would not be that hard, but it would most likely be confusing since you don't know for sure what you have until you look at it and see.

[lolinder]

Rust's deep immutability is different than most in that it allows setting a reference as recursively immutable even if the data type it's pointing to has mutable fields.

Scala gives you immutable data types but unless I'm mistaken there's no way to say "recursively disable mutating functions for all elements in this list"—you just have a list that cannot be mutated. If you stick a Java object in a Scala list, it's liable to mutate, so Scala has shallow immutability.

[danmur]

Yeah that's true, it is different. Neat :). With Scala you would put immutable types in your list if you wanted to, but I get what you mean, it's not the same.

[xmcqdpt2]

Scala's immutable types are also "shallow". For example you can put mutable objects inside an immutable container and change them when you want. Rust avoids this using lifetimes.

It would be interesting if mutability was actually part of Scala's type system, for example if immutable Seq was defined as

    class Seq[T <: Immutable]

[masklinn]

> I don't think they make much sense without the language being statically typed.

They absolutely do, in part because you son’t even have a type system you’d need to undermine in order to achieve mutation.

There are “immutability first” dynamically typed langages, and they work rather well (erlang, clojure).

[capableweb]

> Whether it's JavaScript's `const`

const is JS is referring to the reference and has nothing to do with the value, it's not even shallow immutability, there is none at all.

    const arr = []
    arr.push(1)

is valid JavaScript.

Bit nitpicky maybe, but wouldn't want people to get the impression const gives you any sort of immutability.

[masklinn]

> wouldn't want people to get the impression const gives you any sort of immutability.

const makes the binding immutable but not the object. Object.freeze makes the object immutable but not it’s children.

[cormacrelf]

Accidentally mutating globals was a big problem with the language. Const didn't solve it completely: you can still implicitly create globals by forgetting to declare the binding locally. But at least if you have a global you can make it an immutable binding and get warned about mutating it some of the time (ie assignments). As far as I'm concerned that is all it is useful for. For a local binding you don't really get much benefit since it's not deeply immutable, and it isn't an improvement to the ambiguity of local/global scopes, so you're frankly better off not using it as it will trick newcomers.

The same argument doesn't apply to Data's shallow immutability. It will give you errors when mutating at least some of the fields. If your code can catch you mutating a number, then you can notice the bug and be reminded to make deep copies etc. It's an improvement, just like Object.freeze.

[rtpg]

It's really the same problem extended to attributes of Data. The "immutability" in Data _also refers to the reference_.

To take Python tuples (which are morally pretty close to Data)

  my_data = ([],false)
  my_data[0].push(1)

tuples are immutable, but this happens, because the "immutability" is in the same vein as JS's const: "we are always pointing to the same object".

[lolinder]

This is exactly the same problem that OP was drawing out with Ruby's Data: the references inside the Data object are immutable and cannot be changed to point to other objects, but once you've dereferenced the (immutable) pointers there are no immutability guarantees. Hence, shallow immutability.

The only conceptual difference between this and JS's `const` is that you can't use `const` to declare object properties immutable; for that you need Object.freeze().

[demurgos]

For JavaScript, there's an active proposal to add deeply immutable objects and arrays: records and tuples. [0]

[0]: https://github.com/tc39/proposal-record-tuple/

[nayuki]

> Rust is the main exception I'm aware of, and it had deep immutability from the get-go.

C and C++ have deep immutability too, but both come with many other footguns as baggage.

[inopinatus]

Perhaps even more egregiously: given Ruby's dynamic runtime, we may take an apparently immutable instance of a data class and variously prepend, extend, refine or define methods upon that object's class or eigenclass such that, one way or another, different values are returned, for subsequent uses of that object, with your choice of lexical or global scope, including effecting mutability to the extent of providing viable setter methods.

Actually doing so breaks the covenant of Data, but an enforced prohibition breaks the language. As with Struct before it, a data class is merely a shorthand.

[prescriptivist]

> Actually doing so breaks the covenant of Data, but an enforced prohibition breaks the language.

Fortunately in my almost 20 years of ruby, dark magic does not survive a reasonable amount of sunlight. Most of the time someone (including me) has written impolite ruby, they know what they are doing and why (laziness 90% of the time) and respond appropriately to a gentle prod to be more polite.

[JohnBooty]

This has been my experience as well.

Ruby gives you footguns and you can certainly do ill-advised things... but in practice I just don't see it happening very often either in open source projects or in private corporate stuff.

Why?

Because IME there's rarely even a need to go down those paths at all, unless you are writing a framework or doing something else "meta."

99.99% of Ruby I have actually seen is either simple scripts or bog standard OO stuff.

[inopinatus]

> a framework

We do find such horrors lurking in the bowels of Rails, unsurprisingly. ActiveSupport clamps on to several fundamental modules, but Rails only inflicts the worst of its metaprogramming gymnastics either upon itself, or client objects/classes that expect a ton of magic (viz. models, controllers, views). When peeking at some of the machinery I'm sometimes unsure whether to be appalled or astounded.

[prescriptivist]

Agreed. And if you have a rigid tests-are-necessary-to-merge regime you end up finding that the simplest way to write quality tests are simple approaches to implementations.

[aardvark179]

Java made the same compromise with records, and likely for similar reasons. Limiting fields of such structures to only contain immutable objects ends up limiting their adoption too much even though it may be the way you would like people to use them in the long term.