Dart style question: mutable vs immutable

[Hunter Freyer]

I'm trying to decide whether to make my data model mutable or
immutable in my Dart project. I greatly prefer to design my APIs
around immutable objects, but I'm not clear on how much that affects
performance.

To be more concrete, my model has a "Shape" object which is a
collection of "Point"s. I'll be translating and rotating the shape
frequently, which means going into each of the Point objects and
changing their coordinates. I can either make "Shape" mutable and my
"Translate" method will modify the Shape itself, or I can make it
immutable, and a call to Translate will return a whole new immutable
Shape.

Is Dart designed to have an allocator that can smartly reuse short-
lived objects? I'm more asking about the language philosophy, rather
than the implementation as it stands. Regardless of how it actually is
right now, I want to do the Dartier thing.

kthxbai,
Hunter

[Bob Nystrom]

On Sat, Mar 3, 2012 at 7:53 PM, Hunter Freyer <y...@hjfreyer.com> wrote:

I'm trying to decide whether to make my data model mutable or
immutable in my Dart project. I greatly prefer to design my APIs
around immutable objects, but I'm not clear on how much that affects
performance.

Like most high level languages, it's hard to answer "how much" for Dart here. This is especially true when you consider that we have both a native VM, and we compile to JS which may then be run in any number of different JS engines.

If you find immutability makes your code easier to maintain and reason about, by all means go for it. If you determine that it's a performance bottleneck, consider easing off a bit. I don't think there's a simple blanket answer here that doesn't require some judgement on the part of the API designer.

Is Dart designed to have an allocator that can smartly reuse short-
lived objects?

Even if our VM does, there's no guarantee that every JS engine out there will too. As always, you have to profile and see where your pain points are.

 

I'm more asking about the language philosophy, rather
than the implementation as it stands. Regardless of how it actually is
right now, I want to do the Dartier thing.

I think many of us like immutability. However, a key design decision for Dart is that there is no shared state concurrency. Two threads can never mutate the same object. You don't have to worry about locks, semaphores, etc. Given that, immutability is nice for reasoning about code, but it isn't as critical for maintainability as it might be in, say, Scala or Clojure where immutability is also helpful for safely sharing state across threads.

Cheers,

- bob

[Ladislav Thon]

I think many of us like immutability. However, a key design decision for Dart is that there is no shared state concurrency. Two threads can never mutate the same object. You don't have to worry about locks, semaphores, etc. Given that, immutability is nice for reasoning about code, but it isn't as critical for maintainability as it might be in, say, Scala or Clojure where immutability is also helpful for safely sharing state across threads.

While I agree that immutability is an immense help when dealing with concurrency in shared-memory world, I think that it's biggest advantage lies in API design. You are allowed to pass immutable objects freely to foreign code and not worry about them -- which you currently can't do with dart:io.File, for example. That sucks.

Generally, I'd advise to use immutable objects in Dart on the same occasions as in single-threaded Java or C#.

LT

[Paul Brauner]

On Mar 8, 2012 10:49 AM, "Ladislav Thon" <lad...@gmail.com> wrote:
>>
>> I think many of us like immutability. However, a key design decision for Dart is that there is no shared state concurrency. Two threads can never mutate the same object. You don't have to worry about locks, semaphores, etc. Given that, immutability is nice for reasoning about code, but it isn't as critical for maintainability as it might be in, say, Scala or Clojure where immutability is also helpful for safely sharing state across threads.
>
>
> While I agree that immutability is an immense help when dealing with concurrency in shared-memory world, I think that it's biggest advantage lies in API design.

+1, to me that's at most as important.

[Paul Brauner]

I meant at least :)