Sealed & Frozen Object/Array Syntax

# Keith Cirkel (7 years ago)

As functional programming because more mainstream - developers are leaning more and more on immutability - with tools like immutable.js. However there exists perfectly good solutions inside of JS with Object.seal & Object.freeze.

I propose making a short syntax to allow for creating of sealed/frozen objects that looks like this:

{| foo: 1 |} // same as Object.seal({ foo: 1 })
{# foo: 1 #} // same as Object.freeze({ foo: 1 })

[| 1, 2, 3 |] // same as Object.seal([ 1, 2, 3 ])
[# 1, 2, 3 #] // same as Object.freeze([ 1, 2, 3 ])

// Deep frozen objects becomes a case of using frozen notation all the way
down:
{# foo: {# bar: 1 #} #} // same as Object.freeze({ foo: Object.freeze({
bar: 1 }) })
[# [# 1, 2 #], [# 3, 4 #] #] // same as
Object.freeze([Object.freeze([1,2]), Object.freeze([3, 4]])

This short syntax allows for a much more expressive way of writing/reading sealed & frozen objects. I look forward to a discussion about this.

# Michał Wadas (7 years ago)

However there exists perfectly good solutions inside of JS with Object.seal & Object.freeze.

Actually these solutions are very bad for immutable data structures, because creating deep copy of object on every modification cause very significant overhead. This overhead can be significant even in optimized Haskell implementations (link wiki.haskell.org/GHC/Memory_Management) and for imperative

languages it's even worser.

Immutable.js use many of tricks to avoid deep copying.

# J Decker (7 years ago)

On Mon, Jul 17, 2017 at 2:19 AM, Michał Wadas <michalwadas at gmail.com> wrote:

However there exists perfectly good solutions inside of JS with Object.seal & Object.freeze.

Actually these solutions are very bad for immutable data structures, because creating deep copy of object on every modification cause very

If you're mutating an immutable object you're kinda breaking the rules and it shouldn't have been immutable in the first place.

# Isiah Meadows (7 years ago)

How about no. That is a very wasteful way to model immutable data (which isn't used by most JS developers to begin with), and it's also a very bad way to model the syntax. You also have a potential syntax conflict (requires a substantial cover grammar to avoid) with stage-2 private fields:

class C {
    #foo = 1;
    list() { return [#foo#] }
}

In general, we should be making it easier for decently good libraries (e.g. Immutable.js, mori) to integrate with the language, not provide nice-to-haves that only haphazardly replace them.

Isiah Meadows me at isiahmeadows.com

Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com

# Andreas Rossberg (7 years ago)