Class AcceptableModuleSizeOrError

java.lang.Object
org.ek9lang.compiler.phase5.AcceptableModuleSizeOrError
All Implemented Interfaces:
BiConsumer<String, List<ParsedModule>>
class AcceptableModuleSizeOrError extends Object implements BiConsumer<String, List<ParsedModule>>
Validates the number of constructs declared in a module against MetricLimits.MODULE_SIZE and emits E11027 if exceeded.

This is the god-module backstop. It is deliberately blunt and deliberately generous: AcceptableModuleCohesionOrError (E11017) is the real design signal, because it distinguishes 200 tightly-related constructs (fine) from 100 unrelated ones (not fine), which a raw count never can. A count only catches the case cohesion cannot - a module that keeps growing while staying technically connected.

Parameterised types are NOT counted. EK9 creates each monomorphised List of String in the module that declares the GENERIC, not the module that uses it. So counting generated types would (a) let one module's usage inflate another module's size, and (b) make the limit effectively unhittable-by-design for any module exporting a generic. The count is taken from ModuleCohesionTracker, which is populated by the phase-5 listener walking the PARSE TREE - synthesised types never appear there, so they are excluded by construction rather than by a filter that could later drift out of step.

Built-in modules are exempt, as they are for cohesion.