refactor:Serialisible concept by rprospero · Pull Request #2560 · disorderedmaterials/dissolve

rprospero · 2026-07-24T13:03:18Z

This PR replaces the old Serialisable class with class with a pair of concepts. This provides the following advantages

The concepts can be in different namespaces. Instead of the old, confusing fromVector and toVector methods, we now have Serialisable::vector and Deserialisable::vector methods
The handling of classes and raw types are now unified. Previously, we had many helper functions calling foo.serialise, which would fail if foo was a string or a double. The new serialiseOnto method works equally well with classes and raw types
There's no need to inherit from a Serialisable class to produce toml. This also creates smaller classes, as none of the virtual member function pointers are needed
The serialisation helper functions are now in a separate header (serialiserLibrary.h), which is often only needed in the .cpp file and not the .h file.

The fundamental theory of this library is that the overloaded serialiseOnto function serialises things and deserialiseOnto deserialises things. Making a type serialisable merely involves adding another overload to these two functions. For simplicity, I've added a templated overload that works on any type that had the old serialise and deserialise methods that we used before, so most of the code is largely unchanged.

I have the following changes I would like to perform before I pull this PR out of draft

Remove all direct references to toml outside of the serialiser files. This will make it easier to replace the TOML11 library in the future
Remove import of serialiserLibrary.h from an header files. This should prevent a larger library from many downstream files
- src/classes/atom.h
- src/classes/speciesIntra.h

As a guide for preliminary reviews, the best files to look at will be:

src/base/serialiser.h is the new minimal header and establishes the new namespaces and the serialiseOnto and deserialiseOnto method signatures
src/base/serialiserLibrary.h contains both the actual serialisation concepts and the old helper functions
src/classes/speciesSite.cpp gives a good example on how the new library works (mostly the same with cleaner names).

trisyoungs

Direction is good. Made a couple of comments.

trisyoungs · 2026-07-27T14:01:42Z

+    value["sites"] =
+        vector(sites_, [](const auto &sites) { return vector(sites, [](const auto isoWeight) { return isoWeight; }); });
    target[tag] = value;
 }

 // Read values from a serialisable value
 void SpeciesSites::deserialise(const SerialisedValue &node)
 {
+    using namespace Deserialisable;
    clear();

-    toMap(node, "set",
-          [&](const std::string &speciesName, const SerialisedValue &sites)
-          {
-              auto &set = sites_[speciesName];
-              toMap(sites, [&](const std::string &siteName, const SerialisedValue &population)
-                    { set[siteName] = population.as_floating(); });
-          });
+    map(node, "set",
+        [&](const std::string &speciesName, const SerialisedValue &sites)
+        {
+            auto &set = sites_[speciesName];
+            map(sites, [&](const std::string &siteName, const SerialisedValue &population)
+                { set[siteName] = population.as_floating(); });
+        });


I still have a problem with clarity here. I think this refactoring illustrates it pretty well - I'm supposedly serialising a vector, but deserialising a map. Admittedly this might be caused from the underlying type of sites_ being ResolvableKeyedVector, but you see my point!

trisyoungs

Looking really good I think. Couple of moderate comments to consider.

trisyoungs · 2026-08-03T08:43:14Z

+template <typename T>
+concept SerialisablePointer = requires(T a, std::string tag, SerialisedValue target) { a->serialise(tag, target); };


I actually wonder if this is even required now? In Dissolve1 a module had to write out, e.g., a Species* target which it did by just serialising the name. In Dissolve2, I don't think there are any remaining examples of us needing to serialise a pointer value - all of our data is either a concrete member or passed via an Edge (bypassing the need for direct serialisation in the Dissolve1 style). The only possible example might be in the ForcefieldNode, but this could be factored out (if I haven't done so already).

It is still required, but usually indirectly, as in that we're usually serialising concrete objects, but some of those objects then contain pointers. As a quick example, the atomTypes_ vector in Species is a vector of shared_ptr.

Yep, fair comment. Didn't consider the atom type pointers.

trisyoungs · 2026-08-03T09:12:02Z

+// template <typename T>
+// concept SerialisableFromInto = requires(T a,


Old WIP code?

Yep. That was part of an attempt to apply the serialisable concept to vectors of serialisable, but you can't recurse concepts like that.

trisyoungs · 2026-08-03T09:18:20Z

+    index_ = Deserialisable::de<int>(node.at("index"));
+
+    set(Deserialisable::de<Elements::Element>(node.at("z")), Deserialisable::de<Vector3>(node.at("r")),
+        Deserialisable::de_or<double>(node, "q", 0));


OK, so dumb question - I don't see de or de_or obviously declared anywhere? Presumably the de is for deserialise, but I'm not sure I like the brevity in this case as it harms readability.

de is defined on line 190 of serialiserLibrary.h. I'd originally went with the shorter name hoping that the brevity might improve legibility, becoming essentially invisible against the structure of the data. However, that only worked while we were importing the namespaces. Without that, the benefits of brevity are lost. I'm going to move to deser and deser_or, as a parallel to ser.

Change toVector to simply vector Switch fromVector to just vector

This breaks the linking and the compiler ignores the *inline* directive when deciding whether to inline

rprospero mentioned this pull request Jul 24, 2026

refactor: Graph & IterableGraph TOML roundtrip #2559

Merged

rprospero changed the title ~~Serialisible concept~~ refactor:Serialisible concept Jul 24, 2026

rprospero force-pushed the serialisible_concept branch from 99234da to 608a471 Compare July 24, 2026 13:58

trisyoungs reviewed Jul 27, 2026

View reviewed changes

rprospero closed this Jul 28, 2026

rprospero force-pushed the serialisible_concept branch from d0a488a to 3c68748 Compare July 28, 2026 13:16

rprospero reopened this Jul 28, 2026

rprospero marked this pull request as ready for review July 29, 2026 13:00

rprospero requested review from RobBuchananCompPhys and trisyoungs July 29, 2026 13:00

rprospero force-pushed the serialisible_concept branch from a84b581 to eee891d Compare July 31, 2026 08:48

rprospero mentioned this pull request Jul 31, 2026

refactor: Toml11 4.4 #2568

Merged

trisyoungs approved these changes Aug 3, 2026

View reviewed changes

rprospero added 17 commits August 5, 2026 10:55

Stop inheriting from Serialisable

a6a3cef

Get atom.h to compile serialisation

5c1f9ee

Get a bunch more compile working

42152dd

Fix some type issues with SerialisableClass

b792f44

More minor fixes

76d5a94

Change toVector to simply vector Switch fromVector to just vector

Create serialiser and deserialisers for base types

6c253e5

Convert replace toMap and fromMap with just map

b75f0da

Add concept requirements on fromVectorToMap

711de22

Remove unneeded fromVectorToTable instance

9701f0a

Move serialiser library into own file

7e1d9bb

Start cleaning last fromVector functions

6c187e7

Make serialising a non-serialisable type a runtime error

455d3d1

Fix de_or bug

bff3757

Refactor SerialisableData

248be6f

Remove serialiserLibrary.h import in atom.h

b2d72fc

Remove toml::find instances

ec39f79

Remove SerialisableCast concept

4fabced

rprospero added 8 commits August 5, 2026 10:55

Remove library import from speciesIntra.h

c49d785

Stop using "using namespace" for serialisation

d1476f1

Remove inline declarations

dc7453a

This breaks the linking and the compiler ignores the *inline* directive when deciding whether to inline

Uniform Serialisable spellings

65f7a7c

Remove dead code comments

00bb48d

Clean up map function

c22dae7

Rename de to deser for better clarity

439efcf

Fix up box serialiser

ceb43a0

rprospero force-pushed the serialisible_concept branch from eee891d to ceb43a0 Compare August 5, 2026 09:56

rprospero merged commit cf51673 into develop2 Aug 5, 2026
6 of 9 checks passed

rprospero deleted the serialisible_concept branch August 5, 2026 11:11

Navigation Menu

Uh oh!

refactor:Serialisible concept - #2560

refactor:Serialisible concept#2560
rprospero merged 25 commits into
develop2from
serialisible_concept

rprospero commented Jul 24, 2026 •

edited

Loading

Uh oh!

trisyoungs left a comment

Uh oh!

Uh oh!

trisyoungs Jul 27, 2026

Uh oh!

trisyoungs left a comment

Uh oh!

trisyoungs Aug 3, 2026

Uh oh!

rprospero Aug 3, 2026

Uh oh!

trisyoungs Aug 3, 2026

Uh oh!

trisyoungs Aug 3, 2026

Uh oh!

rprospero Aug 3, 2026

Uh oh!

Uh oh!

Uh oh!

trisyoungs Aug 3, 2026

Uh oh!

rprospero Aug 3, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		template <typename T>
		concept SerialisablePointer = requires(T a, std::string tag, SerialisedValue target) { a->serialise(tag, target); };

		// template <typename T>
		// concept SerialisableFromInto = requires(T a,

Uh oh!

Conversation

rprospero commented Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

trisyoungs left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

trisyoungs left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

rprospero commented Jul 24, 2026 •

edited

Loading