Pair Society

[nwinn-student]

What if a user wants a separate instance of pairs to serialize with?

[nwinn-student]

What if a user wants a separate instance of pairs to serialize with?

Oh. So we could pass some way to represent the desired pair table to bs.serializer, which then passes it to table.serializer?

What about the idea for table.serialize existing parameter? Are we going to keep adding on parameters that modify possible initialized values?

If so, it would be better to add a parameter that is of type { pair: PairSociety, ... }.

[nwinn-student]

Oh. So we could pass some way to represent the desired pair table to bs.serializer, which then passes it to table.serializer?

That sounds overly complex. I agree that adding another external function would not be ideal in this scenerio, at least for actually serializing using the pairs table. However, supporting a userdata that points to a protected table requires an external function and modifications to bs.pair and various link functions.

While I like the idea since it will let me spin up pairs for various datasets, I have also explicitly stated that pairs is capable of handling thousands of values. I feel like this idea is more suited towards an extension of bs than bs itself.

[nwinn-student]

I feel like this idea is more suited towards an extension of bs than bs itself.

A variant could suit bs itself, but I know not.

[nwinn-student]

What if a user wants a separate instance of pairs to serialize with?

Pairs is no longer good enough to warrant extended features such as those suggested. At least not to the extent the API will need to be changed. As mentioned in a reply to another comment, this would be perfect for an extension. I may even create the extension myself, but it does not belong in the main form.

As such I will be closing this discussion.