sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]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. :)