Class AbstractOperatorOverFieldsOrError

java.lang.Object
org.ek9lang.compiler.common.RuleSupport
org.ek9lang.compiler.common.TypedSymbolAccess
org.ek9lang.compiler.phase3.AbstractOperatorOverFieldsOrError
All Implemented Interfaces:
Consumer<AggregateSymbol>
final class AbstractOperatorOverFieldsOrError extends TypedSymbolAccess implements Consumer<AggregateSymbol>
C' (Steve, 2026-10-08): an ABSTRACT $, $$ or #? declared on a type that HAS fields, counting inherited ones, is an error (E07185), reported at the abstract operator.

A sub-type's generated (default operator) $, $$ or #? folds in its super's operator only when that operator has a body to call; below an ABSTRACT one it covers the sub-type's own fields (item 116, AbstractSyntheticGenerator.superContributesRepresentation). That is right for a field-less polymorphic root - nothing can be lost - but over a type with fields it silently dropped them (Circle(radius=3) lost Shape's name). So the abstract declaration is only legal where there is nothing to lose: the author of a type with fields gives the operator a body or default operator X (a hand-written body when the fields are not to be exposed). The error appears exactly where the data is.

"Has fields" is THE shared predicate, GeneratedOperatorFields.anyIncludingInherited(IAggregateSymbol). A trait holds no fields, so its abstract operators are always legal. The other generated operators need nothing here: an abstract == or <=> is already E07183 (sameness must be concrete) and ? is always an override of Any's, so an abstract one is E07020 (override and abstract).

Checked in FULL_RESOLUTION, beside E07237 and E07235: every super is linked by then, whatever order the declarations and sources came in. A different code from E07190 (which is reported at the sub-type's default operator when its super has NO such operator): this one is about the super's declaration itself.