On Mon, May 18, 2015 at 6:21 PM, Robert Stepanek wrote:
Sure, I'd suggest to keep my current CL baking until we either agree
on its design or there is a better alternative.
My counter-proposal is https://go-review.googlesource.com/10241

Enforcing a Patch's atomicity is indeed the responsibility of each
DeadPropsHolder implementation, and the interface is per-resource
rather than a 'System', but:
1. I don't expect many such implementations. For example, Dir provides
*os.File values, which do not (and need not) implement it, and I
haven't seen the real-world need to provide something that combines a
Dir (i.e. persistent file data) with in-memory properties
(non-persistent metadata).
2. If an implementation is in fact needed, it seems trivial if you're
already providing your own virtual file system (as opposed to using a
Dir). For example, the MemFS DeadPropsHolder implementation is 20 to
30 lines of code on top of what was already there.

Given that a PropSystem no longer really does anything configurable or
have any state - the 'Mem' in 'MemPS' is now a misnomer - I'd like to
follow up this CL with another that eliminate the concept of a
configurable PropSystem entirely.


You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 13 | next ›
Discussion Overview
groupgolang-dev @
postedMay 6, '15 at 2:02p
activeMay 20, '15 at 7:24a

2 users in discussion

Robert Stepanek: 7 posts Nigel Tao: 6 posts



site design / logo © 2021 Grokbase