Floor compatibility

[ryanheise]

Is your feature request related to a problem? Please describe.

In a past issue, @rrousselGit provided an example of how to integrate with Floor:

#314 (comment)

@freezed
abstract class MyTable with _$MyTable {
  @Entity()
  factory MyTable(String id) = Table
}

@Database(entities: [      Table    ])
abstract class AppDatabase extends FloorDatabase { ... }

At the time, this solution worked because the generated class Table was concrete as required by Floor. At some point after that, the generator was changed to produce Table as an abstract class, and this broke compatibility with Floor.

Describe the solution you'd like

A way to name and annotate a concrete data class. The stable release date of macros is unknown but it looks like it won't arrive until next year, so until then it would be nice to have an option similar to the old approach.

Describe alternatives you've considered

One workaround is mentioned in #314 although it involves manually writing a mirror constructor for Floor which adds to the maintenance burden.

Additional context

None

[rrousselGit]

I'd suggest asking Floor to change instead of Freezed.

I'd rather not have a feature just for one package

[ryanheise]

Thanks for your response, @rrousselGit .

Floor is certainly not the only package that treats data classes as concrete, json_serializable also works on concrete data classes, and it's a fairly widespread practice beyond.

I'd rather not have a feature just for one package

Precisely! I think it is indeed unfortunate that freezed treats json_serializable as a special case in the surface API, and I wondered whether it might have been able to support both floor and json_serializable in a more general way, in terms of surface API, if it had supported concrete data classes which are widely used (not least of which by floor and json_serializable). For example:

@freezed // generate data class code
class MyTable with _$MyTable {
  @Entity()           // generate database code
  @JsonSerializable() // generate json code
  factory MyTable(String id) = Table
}

You're much closer to the nexus of all of this to know whether or not this is feasible, however my preference would be to have a separation of concerns between freezed, floor, json_serializable and other generators, so that we can mix together multiple code generators on the same class, one concerning json, one concerning DB and one concerning the unique things that freezed brings to the table. Thus, allowing the app developer the freedom to mix and match their preferred substitute packages for each of these separate concerns.

Similarly, looking ahead to a post-macro world in which this will in fact be based on concrete classes, what would be nice to see is if we could mix in different macros on the same concrete class to handle separate concerns.

And it seems that supporting concrete data classes would be a way to maximise this interoperability given that concrete data classes is a rather ubiquitous practice outside of freezed, and not just a floor thing.

I'd suggest asking Floor to change instead of Freezed.

With respect to data classes being concrete, Floor is currently more idiomatic than freezed, and presumably freezed WILL become more idiomatic after macros are introduced, so I don't think it makes sense to make Floor conform to freezed's current choice of implementation detail when it is planning to eventually move toward concrete classes anyway.

The two realistic options are a) wait for freezed to become more idiomatic post macros, or b) offer a solution for concrete data classes for the current version in the meantime.

P.S. Do you happen to have a link to the design document on Dart macros? I'd like to stress the importance of interoperability between multiple macro packages applied to the same class.

[rrousselGit]

With respect to data classes being concrete, Floor is currently more idiomatic than freezed

According to who? :)
There's no reason to force an annotated class to be concrete. Interfaces with Redirecting factories are a very widely used way of defining classes.

Macros aren't going to change much here. The abstract class is used to ensure that things like copyWith and stuff are type-safe. It's likely going to stay there.
I see no reason why you think that macros would change something here :)

[ryanheise]

Macros aren't going to change much here. The abstract class is used to ensure that things like copyWith and stuff are type-safe. It's likely going to stay there.

For copyWith, you do not need to create a subclass of the dataclass itself, you can create a subclass of the function type that is assigned to copyWith without forcing the dataclass itself to be abstract. For sealed classes, it obviously introduces an abstract superclass with concrete subclasses, but it is the concrete subclasses that need to be mapped to DB tables, and that is where the concrete part comes in again. It is these concrete subclasses where integration with Floor is a relevant consideration.

(Aside: When you refer to union types, you are really just describing sealed classes and pattern matching which are not the same thing as union types. I mean, at the type system level, this is a supertype, and we've always had those. We do have FutureOr and nullable types.)

You didn't actually respond to my point about json_serializable also operating on concrete data classes, and if you supported concrete data classes, you might be able to handle both json_serializable and floor using a unified surface syntax instead of making an exception for json_serializable, which it seems you admitted was not a good idea.

According to who? :)

According to the Dart language tour and Dart style guide, this is the idiomatic form:

class Person {
  String name;
  int age;

  Person({required this.name, required this.age});

 // toString, ==, hashCode, copyWith omitted for brevity.
}

Or:

class Person {
  String name;
  int age;

  Person(this.name, this.age);

 // toString, ==, hashCode, copyWith omitted for brevity.
}

This is also exactly Floor supports.

Interfaces with Redirecting factories are a very widely used way of defining classes.

What I'm hearing from you is that Floor should change but freezed should not change. But by your logic, if a way of defining classes is very widely used, then a package should support it. The idiomatic form of defining classes above is much more widely used than redirecting factories, and so there is much more of a reason to support it. So while you could say that there is reason for Floor to change, there is even more reason for freezed to change.

On the idiomatic point, while we can grant that redirecting factories are a legitimate pattern in SOME cases, we can't call it idiomatic in circumstances when the only reason we are doing it is because we are implementing a hack to fit into what's possible in the build_runner system which is forcing us to write contrived code. Nobody really "wants" to assign to a factory some internal symbol that doesn't even exist yet until after the build_runner has run, and which is supposed to be an internal implementation detail that never gets exposed, but we are forced to write such contrived code because we are trying to automatically generate Dart code in a build system that doesn't have first-class support for code generation. And of course with macros, you don't have to expose this internal symbol anymore in the surface syntax, data classes can now be "less" contrived and therefore "more" idiomatic.

I see no reason why you think that macros would change something here :)

Macros certainly change this because they add first-class support in the language for what we were originally trying to do, allowing code to be less contrived and therefore more idiomatic. The first-class support for code generation should make it easier for the implementation to represent data classes as plain concrete classes, and to represent sealed classes as sealed superclasses with concrete subclasses. This would cause the fewest surprises when interoperating with other packages and other codebases.

[rrousselGit]

You keep talking about "idiomatic data classes", but there's no such thing in Dart. Data classes aren't a feature yet, and Freezed is trying to implement it.
If anything, in the Flutter community Freezed is one of the idiomatic ways to define a data class + sealed hierarchy.

To begin with, given:

@freezed
class MyClass with _$MyClass {
  @Foo()
  factory MyClass({@Foo() String? a, int? b}) = _MyClass;
}

Then the following will be in the generated code:

@Foo()
class _$MyClassImpl implements _MyClass {
  _$MyClassImpl({@Foo() this.a, this.b});

  @override
  @Foo()
  final String? a;
  ...
}

That's a "concrete class" which should match your standard.

In that sense, you've yet to explain why that doesn't work.
Freezed already should support any package, because it transposes annotations applied on the @freezed class to the generated code.

If there are some cases that don't work, we need a clear description about why that's the case.
Nothing changed with how Freezed handles its generated code. So if the previous solution given worked for Floor, then it should keep working. If it doesn't anymore, then either Freezed or Floor introduced a bug.
I still see the annotation in Freezed's generated code, so I can only assume that Floor changed something.

[ryanheise]

You keep talking about "idiomatic data classes", but there's no such thing in Dart.

I'd rather you address the underlying point, but since this is pedantry, let's move on.

Nothing changed with how Freezed handles its generated code.

But the generated class name in your very example above is clearly different from the example I linked to in my issue. In your #314 example, the user explicitly gives the name of the generated concrete class in the style of #50 , but in your latest example above, the explicitly given name is NOT of the generate concrete class but rather is the name of an abstract class. The generate concrete class has an internal, and UNDOCUMENTED, name. We can't depend on undocumented internal behaviour which could change at any time without needing to abide by semantic versioning.

It would feel safer if this were documented in the README so that we know that the author purposely considered how this package an integrate with code that depends on access to the concrete class. And hopefully with the macro version, the surface level class "just works" as expected without needing to depend on some internal implementation details.

[rrousselGit]

I'm not saying you should write @Database(entities: [_$TableImpl]). But based on #314 (comment), writing @Database(entities: [Table]) worked for them.

And the generated Table as always been abstract.

So the question remains: What changed and why isn't this working anymore?

I'm also not aware of what the error is nor the reason for that error.
What prints in your console when you pass the abstract class to @Database, and
why does Floor reject abstract classes with factory constructors?

[rrousselGit]

I'd rather you address the underlying point, but since this is pedantry, let's move on.

IMO this is a fairly important point in this issue.
The core of the problem is about who should respect who's conventions.

You're arguing that Freezed should respect Dart's convention, and therefore Freezed should adapt to Floor.
I'm saying that there's no Dart convention for what Freezed tries to do, and Freezed is the one introducing a convention. So Floor should adapt to Freezed.

For now, I have no justification why Floor couldn't accept abstract classes.

[rrousselGit]

Let's summarise things a bit:

• At the time, this solution worked because the generated class Table was concrete as required by Floor. At some point after that, the generator was changed to produce Table as an abstract class, and this broke compatibility with Floor.

  This is incorrect. Freezed has always generated an abstract class with redirecting factories.
  If that worked with Floor before, but it doesn't anymore, then it is Floor who changed ; not Freezed.

• Freezed doesn't need any special plumbing to work with json_serializable.
  Freezed only has logic for it to save a few lines of code, and help deal with sealed hierarchies (which json_serializable doesn't help with)

• Contrary to what you said, json_serializable doesn't reject abstract classes. It only cares about the constructor of a class.
  This is valid:

  @JsonSerializable()
  abstract class Example {
    factory Example(int a) = _Example;
    factory Example.fromJson(Map<String, dynamic> json) =>
        _$ExampleFromJson(json);
  
    int get a;
  }
  
  class _Example implements Example {
    const _Example(this.a);
  
    @override
    final int a;
  }

  ...Although Freezed doesn't rely on that when interacting with json_serializable. But it works ; which shows that Floor could reasonably do the same too (unless I miss one reason why Floor cannot support that).

---

From there, I think the only remaining argument is about the "What's the idiomatic way to define data classes".

So far, I'm of the opinion that what Freezed is generating isn't wrong.
I hear you when you complain about some compatibility issue. But I just fail to understand why Floor cannot support abstract classes with factory constructors. That's an equally common pattern in Dart (pretty much all of the Dart SDK is like that).

We could try and force Freezed to generate a concrete class. But I would need compelling reasons to do so.

Fwiw, I personally have plans for other Freezed features that may clash with making the generated class concrete.
For example, one of the commonly requested feature is to support copyWith as a method rather than a getter ; for the sake of implementing an interface that has a copyWith method.
That'd require an abstract class to be generated ; with factory constructors.

As such, I want good reasons before committing to anything.
But I don't know yet the true reason as to why abstract classes are a problem.

[ryanheise]

Let's look at your example from #314 :

@freezed
abstract class MyTable with _$MyTable {
  @Entity()
  factory MyTable(String id) = Table
}

@Database(entities: [      Table    ])
abstract class AppDatabase extends FloorDatabase { ... }

The reason this doesn't work is that the @Database annotation informs Floor that Table is a concrete class annotated with @Entity, having an "idiomatic" constructor to initialise the data fields (idiomatic in the sense I communicated before).

Table does not satisfy these requirements. #50 implied that it would, but it doesn't.