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
The Java and Scala forms of TrialsSkeletalImplementation have odd return types for the methods that yield trials instances - sometimes it's a TrialsSkeletalImplementation, sometimes its a full-fat TrialsImplementation.
In contrast, the methods in the Java and Scala forms of TrialsApiImplementation by and large yield TrialsImplementation.
Furthermore, there are stray definitions of overloads of .several and .lotsOfSize in TrialsImplementation that really belong in the skeleton traits - but the general type signature insanity prevents them from being hoisted elegantly.
This is inconsistent, confusing - but necessary.
The job here is to either face facts and redefine all the return types to be TrialsImplementation, so the skeleton traits are really just places to park methods that really belong to TrialsImplementation but bloat up the source file, or to finesse the types so that the skeleton class methods (and possibly those in the API traits too) all yield the same type - could be TrialsSkeletalImplementation, or maybe a virtual type, or an F-bound type parameter ...
Hopefully this will allow the final hoisting of .several and .lotsOfSize out of TrialsImplementation and into the skeleton traits.
The overall result should be more readable code and less stray bloat in TrialsImplementation.
The text was updated successfully, but these errors were encountered:
The Java and Scala forms of
TrialsSkeletalImplementation
have odd return types for the methods that yield trials instances - sometimes it's aTrialsSkeletalImplementation
, sometimes its a full-fatTrialsImplementation
.In contrast, the methods in the Java and Scala forms of
TrialsApiImplementation
by and large yieldTrialsImplementation
.Furthermore, there are stray definitions of overloads of
.several
and.lotsOfSize
inTrialsImplementation
that really belong in the skeleton traits - but the general type signature insanity prevents them from being hoisted elegantly.This is inconsistent, confusing - but necessary.
The job here is to either face facts and redefine all the return types to be
TrialsImplementation
, so the skeleton traits are really just places to park methods that really belong toTrialsImplementation
but bloat up the source file, or to finesse the types so that the skeleton class methods (and possibly those in the API traits too) all yield the same type - could beTrialsSkeletalImplementation
, or maybe a virtual type, or an F-bound type parameter ...Hopefully this will allow the final hoisting of
.several
and.lotsOfSize
out ofTrialsImplementation
and into the skeleton traits.The overall result should be more readable code and less stray bloat in
TrialsImplementation
.The text was updated successfully, but these errors were encountered: