Fix calling get_attribute_names on committed datatype

[axelboc]

Addresses #80 (comment)

Tested locally with:

• epics.h5 which includes three committed datatypes
• committed_type.h5 which comes from this H5Web issue: Committed datatypes silx-kit/h5web#1699

[bmaranville]

#83 is merged

[bmaranville]

@axelboc I don't mean to hijack your PR but this seemed like a logical place to also make the changes to the Datatype class, supporting attributes.

Do the types look ok?

[axelboc]

Please be my guest! 😊 Looks like I completely missed extending from HasAttrs, thanks.

[axelboc]

Might be cleaner to override this method in the RegionReference class to avoid returning DatasetRegion when invoking this method on other kinds of objects.

[axelboc]

RegionReference doesn't extend HasAttrs, so what I suggested was not possible. Instead, I added signature overrides to the dereference method so that if one passes a RegionReference, the return type is DatasetRegion:

dereference(ref: RegionReference): DatasetRegion;
dereference(ref: Reference | RegionReference): DatasetRegion | getReturnTypes | null;

[axelboc]

Perhaps the term Entity would be more suited? In H5Web, Entity is the base interface, and ProvidedEntity is the union of all entity interfaces that extend Entity, but since the bare term "entity" doesn't seem to be used yet in h5wasm, I see no problem using it. Otherwise, maybe ChildEntity?

[axelboc]

I used Entity, but feel free to rename. I ruled out Object since it's already used by TypeScript.

[axelboc]

Returning a tuple should work and be more accurate:

Suggested change

	items(): Generator<(string | Reference | Dataset | Group | BrokenSoftLink | ExternalLink | Datatype | null)[], void, unknown>;
	items(): Generator<[string, getReturnTypes | null], void, unknown>;

[bmaranville]

This part is generated by the typescript compiler directly, not by me

[axelboc]

Oh right, because you changed the return type of Group#get. I think we can "fix" it by defining the return type explicitly on Group#items.

[axelboc]

Done

[bmaranville]

When I run npm run build, I get a generated hdf5_hl.d.ts that differs from yours, but only in the line endings - all the source files in h5wasm use lf line endings so far (but your committed hdf5_hl.d.ts uses crlf)

[axelboc]

Apologies, I was on a Windows machine. I've added an .editorconfig file at the root of the repo to avoid this issue in the future.