Extension Functions - Annotations for clean DDD

1

I was wondering if you could clear up something for me. If nobody knows, I can still consult the resulting bytecode, but you might know how much fun this is and forgive me for asking (after I searched google and the issue tracker, and did not find any relating information).

Please consider the class Cargo. To allow persistence of this class, but without polluting the domain model with persistence/infrastructure information, the DDD folks have decided to move this information outside.

Now, I am not a big fan of run-time XML validation, so I was wondering, if Kotlin could help me to solve this problem with an extension of annotations on getter functions.

Assuming this simplified pseudo code:

data class Cargo (
    val trackingId:TrackingId,
    val routeSpecification:RouteSpecification
)

Wouldn’t it be sweet, if we could extend those properties with annotations, e.g.:

fun @Column("tracking_id") Cargo.trackingId;
fun @ManyToOne Cargo.trackingId;

With this, we could separate persistence and domain concerns, whilst still allowing compile-time checking our persistence information.

So my question is: Is something like this already possible, planned, or where can I make a suggestion + who else would like to see this (relatively easy byte-code manipulation).

And yes, I know that this is already possible with AspectJ, but to me kotlin is all about finding the sweet spot between productivity and readability, which aspectJ has not really paid much attention to (apart from the awesome eclipse plugin, which is of little use in the even more awesome idea IDE).

2

The semantics of your proposal is completely different from the semantics of extension functions as they exist in Kotlin. Extension functions do not do any bytecode manipulation; they are compiled to static methods in separate classes, and they can be imported separately from the main class when needed, without affecting anything else. Your feature would actually require modifying the bytecode of the class being extended, which no other Kotlin features currently do, and that would raise all sorts of non-trivial design questions.

So no, this is not possible, not planned, and I don;t think this is a direction in which Kotlin could evolve in the future.

3

Pity - but thanks for the clarification. At least I can still resort to AspectJ. :wink: