0

I'm adding Immutable objects support to my Micro ORM called "Symbiotic"

In the case of a create, I need to pass back a newly created version of the value passed in because the object is immutable and I need to update the newly created identity. For non-immutable values I just set the identity property, but obviously I can't do that now. So I'm thinking of adding a new method called CreateImmutable() with a ref for the value and setting the value with the newly created immutable object with the new identity property value and possibly a changed RowVersion property also. The current method return value is the record changed count, so I want the leave that as is.

I know I could take the easy route and force private property setters, but I would rather support pure immutable types.

Does anyone have any thoughts or potential unforeseen issue on my approach?

current method:

public int Create(object value)

proposed new method 1:

public int CreateImmutable(ref object value)

proposed new method 2:

public int CreateImmutable(object value, out object results)
Eric Schneider
  • 101
  • 3
  • 3
    I prefer that `CreateImmutable` actually return an object. That is the "conventional" way of dealing with immutables. Modifying a parameter in-place is suggestive of mutability, not immutability, and if your method always returns 1, there's not much value in returning an `int`. – Robert Harvey Jul 11 '19 at 18:47
  • 1
    If you still want to go this route and preserve your `return int`, I would prefer using `out` instead of `ref` (assuming that I understand correctly what you're trying to do). – Robert Harvey Jul 11 '19 at 18:49
  • thanks for the info. Out requires more dev work but does preserve the original value (not sure it's needed?) ref is simpler yet does not preserve original, but the original variable is also ready for more use with the new Id. I agree with you on the return, I will re-evaluate that. ref: https://stackoverflow.com/questions/1516876/when-to-use-in-vs-ref-vs-out – Eric Schneider Jul 11 '19 at 20:20
  • Also the current api call convention is that the passed-in object is modified. If CreateImmutable returns the new object, it's different than the passed-in object, that seems deceptive to me. A ref or Out is more obvious. Thoughts? – Eric Schneider Jul 11 '19 at 20:25
  • If the passed-in object is modified in-place, there's no reason to have the `ref` or `out` modifier. Objects are already passed by reference. Adding `ref` or `out` merely makes your method slightly more difficult to call. – Robert Harvey Jul 11 '19 at 20:27
  • From a semantic perspective, that your method deliberately modifies an object which presumably is supposed to be immutable seems odd to me, unless you've figured out some way to magically render the object read-only. The users of your library will also find this odd. – Robert Harvey Jul 11 '19 at 20:31
  • See also the comments below [this post](https://softwareengineering.stackexchange.com/a/137351/1204). – Robert Harvey Jul 11 '19 at 20:33
  • If i'm not mistaken I need ref to replace the passed in object because this call will receive an immutable object. But yes typically it's modified (for the identity) – Eric Schneider Jul 11 '19 at 20:33
  • Oh, I guess I misunderstood. So you're signaling your intention to **replace the object** by using `ref` or `out`, correct? – Robert Harvey Jul 11 '19 at 20:36
  • Yes, and I find it confusing that you pass in one value and received a new one from the method while the existing is unchanged. I know this is normal for immutable related work, but it still throws me of sometimes. – Eric Schneider Jul 11 '19 at 20:43
  • Yeah, the logic there is starting to make my head spin. `ref` suggests mutability, but you're using it to enable *object replacement.* That is going to be obscure to some people, who reasonably expect a method that generates an immutable object to do that by returning it from the method. – Robert Harvey Jul 11 '19 at 20:43
  • I'm thinking that someone with immutable intentions would find an out parameter more appealing and clearer? – Eric Schneider Jul 11 '19 at 20:45
  • I think so, but then you'll need two parameters: the original object, and the `out` one. – Robert Harvey Jul 11 '19 at 20:45
  • The reason that returning an immutable object from a method is clearer is because *immutability implies copying.* The only way to modify an existing immutable object is to make a copy of it. That means you should avoid in-place parameters, because that implies modifying in-place an existing object, not returning a new one. – Robert Harvey Jul 11 '19 at 20:50
  • And while I understand that the object you're modifying is not immutable *yet*, it's still not clear to me how you intend to modify a mutable object to magically make it immutable. – Robert Harvey Jul 11 '19 at 21:00
  • 1
    Right. So your "proposed method 2?" Clear as a bell what it does. – Robert Harvey Jul 11 '19 at 21:04
  • Objects for this new call will be assumed to be immutable and create a new copy. I'm just trying to keep the api clean and clear in the context of existing api calls. – Eric Schneider Jul 11 '19 at 21:05
  • @robert if you want to propose method 2 as an answer, I can give you the credit. Thanks! – Eric Schneider Jul 11 '19 at 21:18
  • I prefer `object = CreateImmuttable(object)`. Where you clearly stays that result is returned value and by assigning returned value to existing variable you "remove" previous object. – Fabio Jul 12 '19 at 23:10

0 Answers0