Objects in Axum

Name

Alexey Romanov — Sun, 10 May 2009 16:25:01 GMT

What about "datatype" or simply "data" (as replacement for "schema")?

Design Patterns as External DSLs

justnbusiness — Thu, 07 May 2009 02:13:34 GMT

Design Patterns as External DSLs

More on Immutability

Isolation, Agents, and Message-passing in .NET — Wed, 06 May 2009 22:51:00 GMT

The subject of immutability sparks intense interest among the people who follow our blog, as is evident

re: Objects in Axum

Jon — Tue, 28 Apr 2009 00:55:51 GMT

Making schemata immutable and generating Equals() and GetHashCode() at compile-time both strike me as desirable features for a purpose built language like Axum. I am more than willing to deal with the inconveniences of immutability for the guarantees that come with it.

re: Objects in Axum

Gerke Geurts — Sun, 26 Apr 2009 10:29:56 GMT

Regarding name choice: I've used the term 'Spec' (short for Specification) so far when writing (meta)types that define structure and rules to be implemented by/adhered to by other types.

re: Objects in Axum

Shawn B. — Fri, 24 Apr 2009 23:27:02 GMT

Niklas,

Our scenarios differ. I see exactly what you are getting at.

We will pass our object into some type of RPC via load balancer (hence our stateless nature) and if we require a mutated object, it comes back as a result and so will be a seperate assignment on a clone anyway. But that "clone" should still be read-only. The original at this point is "forgotten".

All other times the call is one-way and we'll never need the object again from the sending side.

Both scenarios are equally as common for us.

The second is the one I had in mind during my lengthy discussions. It forms our backend (where I spend my career) or various integration services and object ownership transfer, as you put it, is the norm.

The customer facing projects however, use the first scenario.

re: Objects in Axum

Shawn B. — Fri, 24 Apr 2009 23:17:29 GMT

I can live with immutability being enforced at the point where the message is transported. On the receiving side, I receive a clone anyway. However, we still modify the payload after reception. At that point, you're saying it is read-only.

I can live with that, though not ideal, if I can very easily create a new "unlocked" clone based on it (ideally the message will give me an unlocked clone without using reflection internally). Then I can continue to modify the new object as I see fit until it becomes a message again. This scenario isn't ideal, but it is better than a pure read-only after contructor approach.

Performance won't suffer terribly. And everyone gets what they want :) Though preferably, I'd like to be able to unlock the locked or specify it not be locked at all. But from your comments, it will be locked and I can live with that as long as I can get an unlocked clone without having to build it myself or use reflection (which is too darn slow for our environment) given our volume of workload.

re: Objects in Axum

Niklas Gustafsson — Fri, 24 Apr 2009 23:10:50 GMT

Let me ask another question:

What if schema instances were mutable, but were "true" transfer objects in the sense that once you sent an instance, it would no longer be accessible within the domain of the sender?

Object ownership transfer, in other words...

re: Objects in Axum

Niklas Gustafsson — Fri, 24 Apr 2009 23:07:36 GMT

Regarding tobi's comment:

While it's true that we don't need schema instances to be immutable since they are always cloned, one of the reasons for making them immutable is so we don't have to always clone them.

Immutability doesn't have to be "hard core" in the sense of no changes after the constructor is called, it can also be that it is mutable until the point when it is sent via a channel port, at which time all instances in the object graph are locked (this will have minimal impact on the implementation of property setters).

Coercing the schema instances to a C# object on the receiving side (compiler-generated code, but not as fast as Clone) means pay-for-play: copying happens only when you really need it.

So, I really don't know what the right trade-offs are here. If immutability is optional, then it is a question of where to enforce that immutability -- is it on the type? The need (or lack of need) to mutate is usually not a type-specific property, it's a component property.

If coercion can be made as fast as Clone, the only downside to immutable schemas is the need to write each payload type that needs mutation twice (once as a schema, once as a C# class). It keeps the type system clean with Helland's inside / outside distinction being clear in the code.

However, I don't know how to do fast coercion without modifying C#, so it's a moot point.

Again, this discussion has been really insightful and very, very, useful to what we are trying to accomplish.

Thank you!

re: Objects in Axum

Niklas Gustafsson — Fri, 24 Apr 2009 22:48:58 GMT

To answer the last question -- they are currently intended as just message payload. One of the reasons for asking about immutability is whether that perspective should change.

Currently, the instances are messages only while they are in their serialized state, logically of physically, and regular instances in between. The rules are enforced when that boundary is crossed.

Regarding another question asked here -- Axum is definitely meant to be used with existing code. However, it is also meant to rein in shared state anarchy, which means that not all existing code will benefit from it. Since its purpose is to impose a certain pattern (isolated islands of single-threaded execution) on the code, applications that can't be tamed obviously won't benefit.