Bug 507628

Comment 1 Ed Willink 2016-11-17 04:42:19 EST

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.

Comment 2 Ed Willink 2016-11-18 09:26:26 EST

(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.

Comment 3 Ed Willink 2016-12-10 06:41:38 EST

Attempting to add a TypeIsNotNull falls foul of Bug 509022 and needs rework of testSerialize_Bug463877 to handle newly diagnosed errors.

Comment 4 Ed Willink 2016-12-14 14:12:54 EST

(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.

Comment 5 Ed Willink 2018-11-08 09:54:12 EST

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.

Comment 6 Ed Willink 2018-11-28 05:21:13 EST

Bug 541627 calls for a WFR to prohibit Map safe navigation.

Comment 7 Ed Willink 2018-12-07 06:03:44 EST

Bug 443003 identifies a need for an unambiguous implicit opposite name WFR.

Comment 8 Ed Willink 2018-12-30 10:52:42 EST

Bug 443003#c13 identifies the need for a WFR to detect attempts to use non-exactly unit multiplicity Map-valued TypedElements.

Comment 9 Ed Willink 2019-02-20 06:29:23 EST

Bug 544622 requires null-safe validation of Operation Parameters.

Comment 10 Ed Willink 2021-07-21 07:50:45 EDT

Bug 520440 stresses nullity/validity. There seem to be validation of correct nullirt of operation arguments or iterator variables.

Comment 11 Ed Willink 2021-07-21 07:54:26 EDT

(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.