Help reduce boilerplate (best practices or further optional source_gen) about built_value.dart HOT 6 CLOSED

Hi Filip,

Good questions.

The main thing you can do to reduce the boilerplate is to stop writing the builder yourself. If you do that, a default/empty one is generated for you. I notice you're initializing some values to defaults -- but you could do that in your "initialized" constructor instead. Would that work?

The other thing I notice in your code is that your builder holds a "BuiltList". You could instead have it be "ListBuilder"; this is what it will default to if you don't define your own builder. This will save you a bit of typing:

factory FightSituation.initialized( Iterable<int> playerTeamIds, Iterable<int> enemyTeamIds) => new FightSituation((b) => b ..playerTeamIds.replace(playerTeamIds) ..enemyTeamIds.replace(enemyTeamIds));

The idea of built_value is absolutely to minimize the amount of boilerplate you end up writing, so we can dig into this until we hit something that looks optimal :)

from built_value.dart.

Thanks, this is extremely helpful!

In the end, it's easier for me to implement Situation instead of extending it. It doesn't let me share some code but at least it works.

A feature request would be to have a section in the readme (or an example in examples/) with a concrete tutorial on how to solve inheritance vs BuiltValue. I think that even if most of this tutorial would be copy-pasted from your reply above, it would be helpful.

Unless I'm mistaken, the idea of having many classes that inherit from A, which itself is a BuiltValue, will be quite a common use case.

Btw, I'm not sure if that's unsupported or a bug, but if I have:

abstract class Situation<V extends Built<V, B>, B extends Builder<V, B>>
    implements Built<V, B> {
  // ... common interace ...
}

and then I want a built value like this:

abstract class FightSituation
    implements Situation<FightSituation, FightSituationBuilder> {
  // ... concrete implementation ...
}

then the source generation fails with this:

// **************************************************************************
// Generator: BuiltValueGenerator
// Target: abstract class FightSituation
// **************************************************************************

// Error: Invalid argument(s) (builtParameters): Must not be null

I have to explicitly implement BuiltValue for this to work:

abstract class FightSituation
    implements
        Situation<FightSituation, FightSituationBuilder>,
        Built<FightSituation, FightSituationBuilder> {
  // ...
}

Should I file this as a bug?

I'm closing this one because my issue has been solved 👍

from built_value.dart.

I spoke too soon. In the end I dropped the requirement that the Situation class must implement BuiltValue, and I go by convention. It was just too much hassle.

from built_value.dart.

FYI with the latest version relaxing what you can do with the factory, you can now set defaults in the default factory, e.g.

  factory Dialog([updates(DialogBuilder b)]) =>
      new _$Dialog((b) => b
        ..inProgress = false
        ..update(updates));

from built_value.dart.

Is the "relaxing what you can do with the factory" documented? I think I can grasp the constraints from your example but it would be better to be sure.

I still use the three constructor everywhere (factory FightSituation.initialized(...), factory FightSituation([...]) = _$FightSituation and FightSituation._();) and that sucks.

from built_value.dart.

The constraint is that you have to mention the generated type. i.e. anything with _$FightSituation in it is allowed.

This is pretty arbitrary -- if that's too tight we can loosen it further.

from built_value.dart.