Immutable Aspect

johe26's Avatar


13 Feb, 2015 09:30 AM

The Immutable aspect is great but when I tried it I soon ran into what I think is a very limiting contraint for immutable classes that use composition of other immutable classes. The Immutable aspect relies on the Aggregatable aspect and that in turn means that I have to mark fields with the Child attribute. The problem then is that Child[ren] can only have one parent. One of the advantages of immutable objects is that they can be shared between different other immutable objects throughout the program since they can't be changed. I can't see how I would do that with PostSharp Immutable.

  1. Support Staff 1 Posted by PostSharp Techn... on 13 Feb, 2015 11:54 AM

    PostSharp Technologies's Avatar


    This is a very good remark.

    When you need to reuse an object with different parents, you cannot represent this relationship as a [Child] but as a [Reference]. We may need to think about an alternative for this scenario, because you want something between [Child] and [Reference, for instance a [SharedChild]. I'll keep think about that, but in the mean time you can just choose between [Child] and [Reference].


  2. 2 Posted by johe26 on 13 Feb, 2015 12:34 PM

    johe26's Avatar


    [SharedChild] or similar would be greatly appreciated.

    / Johan

  3. Support Staff 3 Posted by PostSharp Techn... on 13 Feb, 2015 01:36 PM

    PostSharp Technologies's Avatar

    We were discussing it here internally and it seems the best option would be to have a validation attribute that you would put on the [Reference] property/field, which would validate that the object is read-only. For inspiration you can look at how [RequiresThreadSafe] is done; you would actually do [RequiresReadOnly].

    The difference is that a [RequiresReadOnly] object would be read-only even during the constructor of the first parent (children are mutable when the parent constructor is running). But I think it's a fair side effect given what you're trying to realize.

    Would that solve your problem?


  4. 4 Posted by johe26 on 13 Feb, 2015 02:25 PM

    johe26's Avatar

    Yes, that pretty much solves my problem. However, it would be great with
    something like a StrictlyImmutable aspect that didn't allow use of
    [Reference] i.e. required all references held by the class to also be
    StrictlyImmutable. What I'm after is an attribute applied at class-level
    that guarantees that the object is completely immutable.

    I guess I can do that with an extra attribute to complement [Immutable]
    that checks that all fields with the [Reference] attribute have the
    [RequiresReadOnly] attribute applied to them as well. It also needs to
    make the same checks in the classes referenced by the fields.

  5. Support Staff 5 Posted by PostSharp Techn... on 14 Feb, 2015 07:38 PM

    PostSharp Technologies's Avatar


    This is generally legal for an immutable object to have a reference to a mutable object. There is a difficulty in what you mean an "object". In PostSharp Threading Models it is not an instance of a class but an aggregate of several instances -- aggregated through [Child].

    Now if you want a more constrained model, I think the best thing to do would be just to build it yourself -- not from scratch of course, but from the Immutable aspect and other aspects of your own.

    The idea is that we provide a framework, we provide the difficult bricks, but since we cannot predict all the variety of requirements, we cannot provide an implementation of everything -- neither would it be healthy to go this way.

    So I would suggest the approach of creating your own aspect, starting from a TypeLevelAspect, using an IAspectProvider to add the Immutable aspect to the class, then add more validation to fields and properties as required.

    With this approach, you could build the model you really want, and you will see it's not so hard (we did the hard job for you) and it's fun :)


  6. System closed this discussion on 13 Apr, 2016 10:34 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac