Skip to content

Refactoring PropertyMapping, MapMapping and IterableMapping #200

@sjaakd

Description

@sjaakd

See #157

I wonder if we could make a model that looks a bit more like a real tree, where it should then be totally transparent for the templates to decide what is chained with which invocation. I'm probably missing some details with necessary local variable assignments, try-catch blocks, and so on. But basically, we're dealing with a model of some source code that is representable as an AST. The template parts would then be immensly simpler, I would guess. We're at a point where we do some very heavy lifting in the templates, and when I think of #160, it won't get any easier (which also requires dealing with local variables and all kinds of stuff) - I wouldn't even know where to start on that one with the proposed modification to the templates... :-)

Such an AST approach would require some refactoring of PropertyMapping and downwards. I'm not having a clear idea right now, but it could somehow extend what the MethodReference does with the methodRefChild. Plus some polymorphism. And some hooks to decorate the parent structure for rendering local variable declarations / initializations and try-catch-blocks.

What do you think, is that something you would like to persue?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions