[cg] Split xxxTables into an Impl

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 473672 | | Status | NEW | | Importance | P3 normal | | Reported | Jul 27, 2015 12:12 EDT | | Modified | Dec 07, 2018 04:53 EDT | | Depends on | 542503 | | See also | 471114 | | Reporter | Ed Willink |

Description

xxxTables.java is currently an API tooling nightmare.

Most of the constants are public only to allow the impl/*Impl classes to access them.

If most of xxxTables.java is moved to impl/xxxTablesImpl.java the constants can be accessed via "package" access.

Some constants that are re-used can be regenerated instead in yyyTablesImpl.java.

Those few that are really public API can stay/be delegated from xxxTables.java.

[eclipse-ocl-bot]

By Ed Willink on Jul 27, 2015 13:42

After a quick experiment:

impl/PivotTablesImpl everything package access\ impl/PivotTablesImpl2 selectively exports PivotTablesImpl\ PivotTables extends PivotTablesImpl2

There are four categories of usage, none in QVTd. CodegenCompanyTables is worst:

a) LIBRARY/PACKAGE - leave in PivotTables

b) PivotTablesImpl.Types - re-export

c) PivotTablesImpl.Operations - re-export

d) STR_xxx - re-export

The STR_XXX are almost only used as a JUnit tests convenience to re-use e.g. "classname::constraintname". Probably best replaced by a helper function. Perhaps the facade redirection just gives e.g. STR_IterateExp_c_c_SafeIteratorIsRequired a stable less obscure manual spelling, allowing the auto-generation to evolve.

PivotTablesImpl.Operations. Few usages, a helper function could outwit the API tooling.

PivotTablesImpl.Types. Modest usages, a helper function could outwit the API tooling.

If the helpers use OperationId/TypeId arguments they might be genuinely opaque. But we defer till run-time the discovery that some operation has been discontinued. The helper could synthesize a dummy to avoid a crash and perhaps if it has been discontinued that is all we need.

[eclipse-ocl-bot]

By Ed Willink on Jul 27, 2015 13:46

(In reply to Ed Willink from comment #1)

There are four categories of usage, none in QVTd.

QVTd is not yet contributing any auto-generated AS code.

Experiment above was for PivotTables. OCLstdlibTables is much more extensively referenced for Types/Operations and possibly Properties.

[eclipse-ocl-bot]

By Ed Willink on Dec 07, 2018 04:53

4 years on ....

Evolution of PivotTablesImpl.Types / PivotTablesImpl.Operations is no worse than evolution of the rest of the pivot model. See Bug 471114

Evolution of STR_xxx is the problem, particularly since WFRs are so underdeveloped that name refactoring is very desirable leading to STR_xxx 'deletion's.

The API tooling issue is solved by a helper that takes a qualified name as a String; changed names return null. Unfortunately any symbolic publication of the qualified name just moves the API problem sideways. A hand coded variant of the helper might match the 'nearest' WFR.

The genuine usage issue, persisting a disable WFR-yy capability, in particular enable null-navigation, could be supported by bespoke helpers.

If we implement constraints as operations, Bug 542503, an 'old' WFR can redirect to the 'new' WFR by e.g. "inv oldWFR: newWFR()" ensuring that model generation produces upward compatible declarations that work for individual validation. Full validation can detect the redirection and avoid the duplicate diagnosis / wasted execution time.

Using e.g. "LetVariable::HasInitializer" as a Constraint key is not so bad, certainly better than the ERR_87 that some tools offer, but we must recognise that "HasInitializer" is just as frozen as "ERR_87".

Currently there are 80 names such as STR_LetVariable_c_cHasInitializer that sould be phased out. 5 other names for " ", "closure", "collect", "ocl", "sortedBy" are harmless, but perhaps unstable dependent on string in today's WFR exposition. 23 further STR names including "", are manually preserved to avoid API removal diagnosis.

Each WFR name such as STR_LetVariable_c_c_HasInitializer is used exactly twice in e.g. validateHasInitializer as arguments to CGStringGetSeverityOperation and CGStringLogDiagnosticOperation. The STR is a pragmatism enabling the operations to be String library operations. Alternative constants are PivotPackage.Literals.LET_VARIABLE_VALIDATE_HAS_INITIALIZERDIAGNOSTICCHAIN_MAP which is the EOperation for the Constraint or once Constraints are callable PivotTables.Operations._LetVariableHasInitializer. STR_LetVariable_c_c_HasInitializer is clearly unsafe and redundant. PivotTables.Operations._LetVariableHasInitializer is safe for the two internal usages and is @noextend,@noinstantiate,@noreference. A user callable help can do a model 'search' in PivotTables.Types._LetVariable for "HasInitializer" and 'handle' a search failure.