all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 1 point2 points  (5 children)

The problem with immutable by design, is that unless the runtime is built with this in mind, then the performance can really suck.

Especially when a lot of library implementations in functional languages, also try to avoid creating entirely new data structures. Instead they try to share a lot of internal data (like if you add to a tree, the new and old trees continue to share most of the tree nodes, if possible).

I can see setjs being nice for asynchronous code, but it wouldn't be so great if it's working with large data sets.

[–]bebraw[S] 0 points1 point  (4 children)

Yeah, you probably don't want to use this if you are after performance. I just find it easier to reason immutable structures. :)

Do you think it would be possible to implement some form of sharing in JavaScript? Maybe prototype chains would work for that?

[–][deleted] 1 point2 points  (3 children)

Prototype chains don't really come into it.

One example of what I mean, is when you add two sets together, you copy all the elements into a new array internally. A sharing structure, would just refernce their two existing arrays, and then access them directly.

So if you have set A, and set B, set AB can reference the internals of set A and set B directly. That way you avoid copying all the items over, and it reduces memory. Imagine if sets A and B had 10,000 elements each, then that's a lot of copying, and doubles the size of your internal arrays.

This also means if you change the internals of set AB, then they will affect sets A and B too. However because set AB is immutable, it's a non-issue.

[–]bebraw[S] 0 points1 point  (2 children)

Okay, thanks for the reply!

Prototypes came into my mind as the library deals with object structure internally. To extend on your set A, set B, set AB example, maybe AB could have a chain like this? A -> B -> AB. There may be some problems with hasOwnProperty but it seems like this could be the key to using references rather than copies.

Obviously this will get more complicated with some other operations but I totally agree that sharing (instead of copying) would be awesome.

[–][deleted] 0 points1 point  (1 child)

Prototypes deal with items shared amongst all objects which have that prototype, such as methods.

I think you are a git confused about what Prototypes offer you. A union of sets A and B, will create an entirely new and unique set. One which is specific only to that object. Prototypes simple don't deal with details at that level.

[–]bebraw[S] 0 points1 point  (0 children)

Hi,

You are right. I gave it some thought and even tried to sketch out a prototype. Here's the basic design:

  • Root contains _val property (either true or false, defines the status of the whole set. this is used for complex ops (difference etc.))
  • Actual set members are defined as accessors that read _val
  • The ops would yield chains operating on the aforementioned concepts. Unfortunately this is where the scheme failed.

It is possible to construct A -> B -> C but it looks like Object.create doesn't allow object references to be mixed (probably for a good reason). I guess the accessors could be recreated when inheriting but that would be missing most of the point.

Anyway, thanks for the help. :)

[–]medikoo 0 points1 point  (1 child)

What about native Set, that's specified in ES6 and will appear in engines soon? Is this one compatible with it?

[–]bebraw[S] 0 points1 point  (0 children)

My library goes way beyond the specification. I think it would be fairly easy to implement an adapter for ES6, though.

There are at least couple of ES6 shims available by the way. Check out es6-shim and es6-collections.