This will not compile, or at least, no _$Person will be created.
Is this something you don't want/or is impossible to support?
@immutable
abstract class Person with _$Person {
const factory Person(String firstName, String lastName) = _Person;
String get fullName => '$firstName $lastName';
}
Getters can't work. There's no way to support them since Person is _implemented_ not _extended_.
But you can use extensions:
@immutable
abstract class Person with _$Person {
const factory Person(String firstName, String lastName) = _Person;
}
extension on Person {
String get fullName => '$firstName $lastName';
}
I wonder if it's possible to have the generator "copy-paste" the source code of getters to the generated classes though
Do you think that could cause issues?
I was thinking the same but this feels kind of too much magic.
creating an extension is absolutely fine :) i didn't event think about it.
I'll experiment with it anyway.
That would be a big improvement to the syntax.
The class is immutable and type-safe anyway. It should be safe.
maybe something like this?
@memo
String get fullName => '$firstName $lastName';
Why @memo?
to make it more obvious.
it could generate code
String _fullName;
String get fullName => _fullName ??= '$firstName $lastName';
Hum, I'm not sure caching the result is a good idea.
I'd prefer and wait for the 2.8 with late:
late final fullName = '$firstName $lastName';
alright :)
do you see any advantage by "copy paste" the getter instead of using a simple extension?
It's more natural. That's your first attempt after-all right?
And extensions require a new name + they are located in a different place.
A getter removes the need for a name and keeps things together.
The naive me was like " this getter must automatically work ".
The problem i see with "copy paste" the getter is, that people will change their getter without thinking about rebuilding, because it is not obvious.
forcing them to annotate the getter might help.
Hum I don't mind that.
After all, Flutter tries to support code-generators natively to run them automatically for you.
It's only a matter before we fully stop the build_runner thing
I am +1 for annotation until build_runner really became obsolete.
An annotation package is _horrible_ to maintain. Unless there's a very obvious reason to use an annotation, I would refrain from making one.
I understand. Then i'll +1 for the easiest possible implementation and wait if people "forget" about rebuilding
Honestly I think extension functions are just easy enough to use!
Extensions functions aren't part of the object prototype.
abstract class Foo {
String get fullName;
}
@immutable
abstract class Model with _$Model implements Foo {
factory Model(String firstName, String lastName) = _Model;
}
extension ModelExtension on Model {
String get fullName => '$firstName $lastName';
}
That won't work
Hum. Thinking about it, this wouldn't work with breakpoints.
Another thought:
This would allow the generator to add these to the toString/debugFillProperties implementation.
@immutable
abstract class Person with _$Person {
const factory Person(String firstName, String lastName) = _Person;
String get fullName => '$firstName $lastName';
}
class _Person {
@override
String toString() {
return 'Person(firstName: '$firstName', lastName: '$lastName', fullName: '$fullName');
}
}
I think I'll cancel this and just wait for late (which we can already use actually):
@immutable
abstract class Person with _$Person {
const factory Person(String firstName, String lastName) = _Person;
late final String fullName = '$firstName $lastName';
}
Reopening this as it may be possible without dirty copy-paste trick after all.
We could have:
@immutable
abstract class Person with _$Person {
const Person._();
const factory Person(String firstName, String lastName) = _Person;
String get fullName => '$firstName $lastName';
}
Closing in favor of #83
Most helpful comment
Honestly I think extension functions are just easy enough to use!