I want to suggest an addition to standard library - persistent object module. The idea is straightforward, if we use file mapped memory to store some data, the data may outlive the application and be kept until next application start, thus providing persistent and consistent storage between application runs. Two closest conceptions are obviously serialization and general shared memory, but there are several important moments which make a difference. It differs from serialization mainly by its efficiency and reliability, once the object in shared memory is created it might be accessed with almost same efficiency as any other in-memory value, moreover, it has all the chances to survive process crash or spontaneous stop as modification of any variable takes no time, unlike long serialization process. It also differs from general shared memory in its object-oriented approach, instead of separate allocation and initialization of the shared memory piece, we call ctor immediately returning initialized object with the difference, the object is placed into shared memory. The RAII concept is fully supported, the object is either created and initialized or created preserving its value if it did exist, (btw, this is why I had to create own shared memory functions instead of using existing std module). The module is also natural candidate for interprocess communications, but concurrency primitives are intentionally not included (except atomic creation), instead, various synchronizations may be built on top of it.
  Obviously, it might be used with value types only. The persistent object may contain either simple value or struct or static array, the file is either created or opened and extended if needed. In the last case, the object is initialized, or, in the case of array, only extended part is initialized. The existing part of the memory is kept as is, assuming it already contains initialized values. It might be also created as dynamic array, in this case the length is derived from the file size, and the file must exist.
The code is here: https://github.com/D-Programming-Language/phobos/pull/3625 , please see unittest section for numerous usage examples.
  I used the conception for several years (C++, fast and reliable transaction servers), and it proved to be very useful for such a kind of applications. The module is placed to review queue for voting and discussion. I will be happy to hear your opinion and suggestions.

First things first.

No walls of text please.
White space is a requirement for good design and in this case communication.

As said on PR, make it into a dub package and let it prove itself.
Right now for what it /could/ do and what it does, doesn't quite match up. Show it works in real world, then lets talk.

On Wednesday, 11 May 2016 at 01:25:39 UTC, Sergei Degtiarev wrote:
> [...]

It seems like this review thread slipped under the radar. It is a proposal to have persistent (binary) serialization for objects to files.
Please have a look at the PR and state your opinion ;-)

On Sun, May 15, 2016 at 09:27:55AM +0000, Seb via Digitalmars-d wrote:
> On Wednesday, 11 May 2016 at 01:25:39 UTC, Sergei Degtiarev wrote:
> > [...]
> 
> It seems like this review thread slipped under the radar. It is a proposal to have persistent (binary) serialization for objects to files.  Please have a look at the PR and state your opinion ;-)

This PR has been stagnating in the queue for a *very* long time.  I can't speak for others, but personally, as a Phobos reviewer, I find it very daunting to review such a large PR adding a major new feature that hasn't gone through community peer review or discussion.  This is perhaps one reason for why nobody has paid attention to it, or rather, nobody has dared to do anything about it yet. No one wants to take responsibility for merging a major new feature that's not yet proven, or with a design and/or API that hasn't been shown to work well in the field. (It may actually already be the best API, but without actual user feedback proving this, it's hard to be sure.)

So I think what somebody has already suggested is the best way to go: make it a dub package, and let people actually use it, get feedback, prove it in the field first. Once it's proven, and design issues and API issues are ironed out based on feedback from actual users, then resubmit it to Phobos and perhaps we'll get a better response then.

Hope this helps.


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan

On Wednesday, 11 May 2016 at 01:25:39 UTC, Sergei Degtiarev wrote:
> I want to suggest an addition to standard library
> [...]
> The code is here: https://github.com/D-Programming-Language/phobos/pull/3625 ,

"perpetual" is the name of that novel you'll show to your literature teacher at Yale, but definitevely not the name of a Phobos module ;)