Skip to content

Pin the getObject(n) = get('object', n) equivalence across all three IMetadataService implementations #6745

Description

@qq9340100

Follow-up to #6505 / PR #6723, filed by the PM per the dev's flag (open question 2 of its report).

What

PR #6723 documents, on IMetadataService.getObject, that the pair getObject(name) / get('object', name) resolves through one lookup in every shipped implementation — measured with a runtime probe against all three (MetadataManager, MetadataFacade, createMemoryMetadata): identical object reference on the facade, deep-equal everywhere, undefined on a miss for both members.

That equivalence is now declared but ungated: nothing fails if a future edit to any of the three implementations makes the pair diverge again, and the contract TSDoc would then be lying — the exact declared-not-enforced shape this repo repeatedly pays for.

The work

Add a conformance test asserting, for each of the three implementations:

  • getObject(n) and get('object', n) answer the same thing for a present object (on the facade: the identical reference);
  • both answer undefined on a miss.

The dev's deleted probe (~40 lines, described in PR #6723's report) already passed and is the shape to recreate. Landing site is the implementer packages' test surface (or a shared conformance table if one fits better) — not packages/spec, which has no runtime to test.

Deliberately NOT part of PR #6723: the #6505 ruling scoped that diff to TSDoc only.

Acceptance

One sentence: a test exists that goes red if any shipped IMetadataService implementation's getObject stops answering exactly what its get('object', …) answers.

Refs #6505, PR #6723, #6724 (the stale comment this equivalence contradicts), #6725 (the write-side asymmetry, explicitly out of this card's scope).

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions