Builders should provide accessors to their fields

[yjbanov]

For example, imagine I was to construct a factory that forwards its parameters to a constructor:

class Foo {
  factory Foo(A a, B b, C c) {
    return new Foo._(a, b, c);
  }

  Foo._(A a, B b, C c);
}

To generate factory Foo(A a, B b, C c) I will have a List<ParameterBuilder>. To forward the parameters to Foo._, I want to be able to convert List<ParameterBuilder> to a List<ExpressionBuilder> args and pass that to myType.newInstance(args).

Example:

List<ExpressionBuilder> forwardParamsToArgs(List<ParameterBuilder> params) {
  return params.map<ExpressionBuilder>((p) => reference(p.name)).toList();
}

Unfortunately p.name does not exist.

[matanlurey]

That's a good fundamental question. It's not impossible to do, certainly something like name is easy.

@alorenzen and @natebosch, WDUT?

[natebosch]

I'm curious how often this comes up.

When you create the List<ParameterBuilder> can you create the List<ExpressionBuilder> alongside it?

I could get on board with the idea, though I think in many cases it might be better to go data -> builder1,builder2 than data -> builder1 -> builder2

[zoechi]

Is this similar/related to #40?

[yjbanov]

@natebosch Yeah, creating the two lists (or more, if, e.g., you also want to generate class fields) is a solution. However, it either requires tighter coupling or additional custom data structures for storing information about parameters/fields. A simple example:

var params = data.where(_accept).map<ParameterBuilder>(_createParam).toList();
var args = params.where(_pass).map<ExpressionBuilder>(_createArg).toList();

But since I can't use params, I have to save the results of the first line in something else, which seems redundant as ParameterBuilder is already a perfectly fine object for storing parameter information:

class MyParam { var type; var name; }

var paramData = data.where(_accept).map<MyParam>(_createParamData).toList();
var params = paramData.map<ParameterBuilder>(_createParam).toList();
var args = paramData.where(_pass).map<ExpressionBuilder>(_createArg).toList();

Or avoid list comprehensions and instead run a single loop that couples the two constructions.

[natebosch]

I can see your point. If he had nice Tuples or something this would be easier, but having to define a class is a lot of overhead. I think this feature is worth adding.

Side note: In your examples all of the generic arguments to .map aren't necessary as long as the _create* methods are well typed.

[alorenzen]

Yeah, I can definitely see some value to this.

[matanlurey]

Alright, SGTM.

[matanlurey]

I'm going to add ParameterBuilder#name, but others will have to be added as-needed.

[yjbanov]

Aye!

[matanlurey]

Closing for now, we can re-open for specific needs.