You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SubjectFactory exists to permit some strongly-typed flexibility (assertAbout, as well as a previously deleted, but soon returning iterating-subject wrapper). However, it's entirely computable boilerplate. It should be generated, and subjects decorated with @TruthSubject in order to signal the need to generate it.
The style will be similar to @AutoFactory in that a subject implementor will create a static method to return the SubjectFactory, and will simply return the generated one.
The contract will not be changed, so existing SubjectFactory-returning methods will work, and an implementor is free to follow the convention but create their own SubjectFactory for odd cases such as stateful factories, but for the default case, reducing the burden of the subject writer is important.
The general form will be:
@TruthSubject
public final class FooSubject extends Subject {
// ...
public static class FooSubjectFactory foos() {
return new FooSubjectFactory();
}
}
Since it is, at this point, an optional convenience, complexity will be kept low (e.g., the naming convention of the factory name will be simply FooSubject.getSimpleName() + "Factory"
Additional validation will be performed, in the initial version, which will confirm that there exists a public static method that returns the generated type, registering a compiler error if it is not.
Future validations may be added to this, to clean up subject writing, or to generate
other types that might be needed, such as an iterating subject wrapper, and this processor
will form the anchor-point for those features.
The text was updated successfully, but these errors were encountered:
We've simplified SubjectFactory (nowadays, Subject.Factory) to the point that it's usually just a method reference nowadays, so that part of this issue got resolved in that way instead.
We should still have lots of static analysis for custom Truth subjects. I'll eventually open some feature requests against Error Prone.
SubjectFactory
exists to permit some strongly-typed flexibility (assertAbout, as well as a previously deleted, but soon returning iterating-subject wrapper). However, it's entirely computable boilerplate. It should be generated, and subjects decorated with@TruthSubject
in order to signal the need to generate it.The style will be similar to
@AutoFactory
in that a subject implementor will create a static method to return theSubjectFactory
, and will simply return the generated one.The contract will not be changed, so existing SubjectFactory-returning methods will work, and an implementor is free to follow the convention but create their own SubjectFactory for odd cases such as stateful factories, but for the default case, reducing the burden of the subject writer is important.
The general form will be:
Since it is, at this point, an optional convenience, complexity will be kept low (e.g., the naming convention of the factory name will be simply
FooSubject.getSimpleName() + "Factory"
Additional validation will be performed, in the initial version, which will confirm that there exists a public static method that returns the generated type, registering a compiler error if it is not.
The text was updated successfully, but these errors were encountered: