Omar Jennane

Thanks for raising this issue ! I'll have a closer look and search for possible solutions.

Unfortunately, this is not supported right now. > Is it OK (Modddels-wise) going for: > > ```dart > factory MapLayer.raster( > {required MapLayerPosition position, > required URI uri, > @validParam...

Okay, the `@hasDefault` solution is fairly easy to implement. Only problem is how that would translate to the generated [`ModddelParams` class](https://docs.modddels.dev/unit-testing-of-modddels/unit-testing-overview). Usually, the generated `ModddelParams` has the same constructor as...

Upon reflection, I think we should stick with the rule of the `ModddelParams` class having the same constructor as the factory constructor of the modddel. In our example, this means...

Last thing to figure out is the name of the annotation 😅 : Should we go with `@hasDefault` or something more explicit like `@defaultIfNull` ?

Hi @chikamichi , Wouldn't a `MultiValueObject` be fine ? ```dart // @Modddel( ... class Duration extends MultiValueObject with _$Duration { Duration._(); factory Duration({ required double max, double min = 0.0,...

With the current implementation, all case-modddels are mixins, so they can't have factory constructors. This means we can't have a syntax like this : ```dart final raster = Raster(1); ```...

This change should also apply to ["ModddelParams"](https://docs.modddels.dev/unit-testing-of-modddels/unit-testing-overview) classes. Right now, creating an instance of a case-modddel's `ModddelParams` was done like this : ```dart final params = MapLayerParams.raster(1); // of type...

> With the current implementation, all case-modddels are mixins, so they can't have factory constructors. With the new dart 3.0 class modifiers, we can do: ```dart abstract mixin class Raster...

This feature would be SO valuable, along with the ability to nest blocks inside tables. I hope this gets implemented soon ! 🙏