[MDSAL-44] Autoboxing support Created: 04/Aug/14  Updated: 09/Jan/24

Status: In Review
Project: mdsal
Component/s: Binding codegen
Affects Version/s: None
Fix Version/s: 14.0.0

Type: Improvement Priority: Low
Reporter: Ed Warnicke Assignee: Samuel Schneider
Resolution: Unresolved Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Issue Links:
Blocks
is blocked by MDSAL-237 Milestone: Implement Binding Specific... Resolved

 Description   

In situations where we have a containing element which has as its child a single container, we should make it easy to autobox it.

Example: 

choice ch {
  case foo-case {
    container foo {
      ...
    }

  }
}

foo-case contains a single container, foo. We should add an interface to Foo AutoBoxAble<FooCase>, and provide it a method

class Foo {
  ...

  public FooCase autoBox() {
   // wraps Foo in FooCase and returns it
  }
}
 

The same can also be done for containers:

container bar-container {
  container bar {
     ...
  }
}

public class Bar {
  public BarContainer autoBox();
}

 and lists

list baz-entry { container baz { ... } }

public class Baz { public BazEntry autoBox(); }

Note, this would be done only in the case where there was only where there is a single container child.

 Comments   
Comment by Robert Varga [ 04/Aug/14 ]

I actually think this should not be implemented in the interfaces themselves, but rather should be a method in the associated builder, e.g.

 

class FooBuilder {
 
  Foo build() {
     ...
  }
  FooCase buildBoxed() {
    return new FooCaseBuilder().setFoo(build()).build();
  }

}

 

That way it is not part of the specification of the object itself, but rather a real convenience function, just as the entire builders are.

Also, this can be generalized to any class which

implements ChildOf<T>

where !(T instanceof Identifiable) and T does not place any structural requirements (must/when) on existence/value of Foo – as that would trigger an assertion failure at runtime.

Comment by Ladislav Borak [ 13/Aug/14 ]

proposed patch: https://git.opendaylight.org/gerrit/#/c/9744/

Comment by Robert Varga [ 08/Oct/20 ]

Okay, reformatted this thing and I think I am finally getting (again?) what is it what we want to do.

So this is 'traverse upwards' builder and product propagation, really. We are attempting to this::

public FooCase buildCase(String bar) {
  return new FooBuilder()
    .setBar(bar)
    .buildCase();
}

Now in fluent form, we do not want to go directly from FooBuilder to FooCase. What we really want to do is this:

public FooCase buildCase(String bar) {
  return new FooBuilder()
    .setBar(bar)
    .startFooCaseBuilder()
    .build();
  }
}

FooBuilder is handing itself to a FooCaseBuilder, i.e. a purely implementation flow thing to become:

 

public FooCase buildCase(String bar) {
  return new FooBuilder()
    .setBar(bar) 
    .startFooCaseBuilder()
    .build();
   }
}
 

if we peel the .build() step, we have a self-similar pattern:

interface Foo extends ChildOf<FooCase> { };

class FooBuilder implements Builder<Foo> {
  public FooCaseBuilder startFooCaseBuilder() {
    return new FooCaseBuilder(this.build);
  }
}

i.e. we can fluently continue building the FooCase from that property or directly build it.

Comment by Iaroslav Kholiavko [ 23/Nov/20 ]

New patch: https://git.opendaylight.org/gerrit/c/mdsal/+/93856

Based this one: https://git.opendaylight.org/gerrit/c/yangtools/+/9744

Generated at Wed Feb 07 20:08:30 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.