"dogs" constructors don't seem to work when the dogs constructor is on a base class

[point-source]

"dogs" constructors don't seem to work when the dogs constructor is on a base class

[helightdev]

Implemented in

dogs_core: ^8.0.1

[helightdev]

@serializable
class InitializersModel with Dataclass<InitializersModel> {

  final String id;

  InitializersModel(String? id) : id = id ?? "default";

  factory InitializersModel.variant0() {
    return InitializersModel(null);
  }

  factory InitializersModel.variant1() {
    return InitializersModel("id1");
  }
}

@serializable
class ConstructorBodyModel with Dataclass<ConstructorBodyModel>{

  late String id;
  late String data;

  ConstructorBodyModel(String? id, String data) {
    this.id = id ?? "default";
    this.data = data;
  }

  factory ConstructorBodyModel.variant0() {
    return ConstructorBodyModel(null, "data0");
  }

  factory ConstructorBodyModel.variant1() {
    return ConstructorBodyModel("id1", "data1");
  }
}

@serializable
class GetterModel with Dataclass<GetterModel> {

  late String id;
  String? _buffer;

  GetterModel(String? id, String data)  {
    this.id = id ?? "default";
    _buffer = data;
  }

  @PropertyName(r"$data")
  String get data => "$_buffer";

  factory GetterModel.variant0() {
    return GetterModel(null, "data0");
  }

  factory GetterModel.variant1() {
    return GetterModel("id1", "data1");
  }
}

Next release will satisfy those special cases where getters and non-formal parameters are used

[point-source]

Beautiful, thanks!

[helightdev]

Feel free to reach out if you encounter anything else you are missing from the package. Really appreciate it.

[helightdev]

Forgot to add support for super fields, I'm on it

[helightdev]

fixed in ca2787e

[helightdev]

Forgot to add support for super fields, I'm on it

I originally wrote this part of the generator when super formal parameter were relatively new (or not even implemented, I can't remember fully), so I basically just forgot to add support for it. Didn't need much change though.

[helightdev]

Though you will probably still have a small problem with your code, since the super.id is not a field reference but a default constructor argument. The dogs constructor of the base type is not used in the implementation so it will not be considered in this case, since the field name resolution is handled through the constructor parameter association. If you want to initialize the id field using a random uuid, I would make the field explicitly not private and perform the initialization in the constructor block.

abstract class Base {
  String? id;

  Base({this.id}) {
    id ??= const Uuid().v4();
  }
}

@serializable
class User extends Base with Dataclass<User> {
  final String username;

  User({
    super.id,
    required this.username,
  });
}

[helightdev]

The cleaner way would still be not generating the uuid inside the model class, but specifying it when you create a new instance of the object. This would be the "advised" way to handle this problem with dogs. The model files are meant to stay relatively clean and decoupled from the rest of the code, being inherently static in their nature.

[point-source]

Thanks for the quick update!

The reason I do it the way I do is because I don't want the class variable to be nullable. That said, I could use your example but modify it by using "late" to workaround that issue.

EDIT: Jk, can't seem to use "late" in this case. I would hate to be stuck with nullable class variables here. That's probably a dealbreaker. So that means moving to a required variable in the constructor.

As for the model files remaining static and decoupled, I tend to agree as I continue to move further into functional programming. That said, I really wish that making standalone factory methods was as convenient as adding constructors. Having to write out all the field types by hand rather than using "this." is pretty annoying. Open to new ideas for streamlining cases like this.

Here is another example where I find this useful:

@serializable
class Task with Dataclass<Task> {
  final String clientId;
  final DateTime addedAt;
  final DateTime updatedAt;
  final DateTime? completedAt;
  final int progress;
  final Status status;

  Task({
    required this.clientId,
    required this.addedAt,
    DateTime? updatedAt,
    this.completedAt,
    required this.progress,
    required this.status,
  }) : updatedAt = updatedAt ?? addedAt;
}

[helightdev]

I just thought about this issue a bit and I actually agree that the rules for constructors might be a bit too restrictive. I will think about a way to make factories and non-field parameters work with the system. This will take a bit of time to fully implement though.

As for the is field, you could also name it $id, make it nullable and add an getter for accessing with '!'.

[helightdev]

My current idea would be taking the name of the parameter and looking up the class members if a field or getter for this name exists. About nullability,the constructor parameter will dictate it. Annotations will still have to be placed on the getter or field, annotations on constructors are ugly.