Community
Participate
Working Groups
Pivot.ocl has gradually grown (and shrunk). There are many bugs suggesting a bit of better validation. This planning bug gathers them all together.
Any change to Pivot.ocl causes API tooling difficulties. This has demotivated some attempts at improving WFRs. Waiting for 2.x is not an option while most effort is going into QVTd. Must enhance now. New names can be @since'd or API filtered away. Old names can be restored in stub form by @generated NOT to EMF files. PivotTable may need a new 'synonym' capability defined by EAnnotations to preserve names. EMF interface files can be @noinstantiate'd to allow minor version additions. EMF constants cannot unfortunately, Bug 507631, be @noreference'd to hide the constant changes since they are of course defined specifically to be referenced.
(In reply to Ed Willink from comment #1) > New names can be @since'd or API filtered away. Almost any spelling change leads to an API breakage, which can be API filtered. e.g. correcting "initialise" to "initialize" => breakage e.g. migrating a Variable::constraint to LetVariable => breakage e.g. deleting the obsolete per-iterator-name constraints => breakage It is difficult to claim that PivotValidator is really the same class. Derivations are definitely broken, but are there any? QVTd derived validation is still to do. Options: a) pedantic API tooling compliance, minimal API filtering - we cannot add new Pivot.ocl contraints (until Pivot moves to 2.0) b) more pragmatic API tooling compliance, API filtering only for additions - we can add new constraints to Pivot.ocl - all old Constraints must be retained even if obsoleted as "true". - reflective consumers e.g. the Validation View will be bloated c) very pragmatic API tooling compliance, API filtering for addition and removal - we can add/change/remove constraints in Pivot.ocl - derived PivotValidator is seriously broken without a rebuild - derived PivotPackage has changed constant values, get_constraint names - standard EMF gotcha --- After reviewing the API filters for c), the removes are hard to justify. b) isn't too bad. Just requires that all obsolete constraints are retained as "true". Bug 507658 fix introduces relevant per-derived Variable WFRs. --- The OCLstdlib merging fals to support overloaded constraints. M3 tooling fails to report all missing @since's.
Attempting to add a TypeIsNotNull falls foul of Bug 509022 and needs rework of testSerialize_Bug463877 to handle newly diagnosed errors.
(In reply to Ed Willink from comment #3) > to handle newly diagnosed errors. Tests now assert the expected errors so that M4 has TypeIsNotNull and NameIsNotNull invariants. M4 supports extension so that QVTd has autogenerated OCL WFRs too.
While adding Map.collectBy, I inadvertently introduced a duplicate V template parameter. No diagnosis of operation template parameter hiding class template parameter. Ultimate 'diagnosis' was obscure UOE. Need template WFRs.
Bug 541627 calls for a WFR to prohibit Map safe navigation.
Bug 443003 identifies a need for an unambiguous implicit opposite name WFR.
Bug 443003#c13 identifies the need for a WFR to detect attempts to use non-exactly unit multiplicity Map-valued TypedElements.
Bug 544622 requires null-safe validation of Operation Parameters.
Bug 520440 stresses nullity/validity. There seem to be validation of correct nullirt of operation arguments or iterator variables.
(In reply to Ed Willink from comment #10) > nullirt nullity or validity Also changing operations such as regexes to query-returning-null rather than assertion-returning-invalid causes very few tests to fail.
