Make it possible to implement ResourceIdentifier

[HosseinYousefi]

ResourceIdentifier is currently not a final class. However, it won't behave correctly if we subclass it, and use the subclass as an annotation, since we're checking it based on the name.

I would like to be able to implement it for jnigen, so I don't have to repeat certain things in the generated code. For example:

class JClassIdentifier implements ResourceIdentifier {
  final String name;
  final String somethingElse;

  const JClassIdentifier(this.name, this.somethingElse);
}

@JClassIdentifier('Foo', 'Bar') // instead of @ResourceIdentifier('jnigen-Foo-Bar')
late final JClass foobar;

@mosuem
cc/ @dcharkes

[lrhn]

since we're checking it based on the name.

Yeah, there's the issue.

Can you even do:

const myResource = ResourceIdentifier(...);

@myResource
Some declaration...

?

[mosuem]

Yes, the current check is name and library only. I like the idea of subclassing!

[dcharkes]

I think we should likely disallow implementing, because the metadata field could not exist in a subclass.

Also, we should specify what happens to subclasses specifying more fields. Are they reported in the resources.json? If they are reported, we should come up with an encoding that does not lead to potential conflicts.

class JClassIdentifier extends ResourceIdentifier {
  final String name;

  const JClassIdentifier(this.name)
      : super('jnigen');
}

This would currently lead to a class between name in the annotation and name of the method the annotation is on in how it's currently encoded.

@mosuem @HosseinYousefi @lrhn Any preferences on if the metadata field is special and the only one reported, or if we report all fields?

[HosseinYousefi]

@lrhn
Unrelated question: why can we create a const string but not a const map from const constructor's arguments?

class JClassIdentifier extends ResourceIdentifier {
  const JClassIdentifier(String name, String somethingElse)
      : super(const {name: somethingElse}); // Error!
}

I assume it's because the const string and string have the same syntax but const map requires an extra const keyword. It would be nice to have something like "preferConst" so we could do

class JClassIdentifier extends ResourceIdentifier {
  const JClassIdentifier(String name, String somethingElse)
      : super(preferConst {name: somethingElse}); 
}

Since making {name: somethingElse} to be "preferConst" by default is a breaking change.

[HosseinYousefi]

Any preferences on if the metadata field is special and the only one reported, or if we report all fields?

Since we can't quite fill the metadata as a map using the arguments of the subclass' const constructor, I prefer it if we report all fields if possible.

[dcharkes]

We intend to make ResourceIdentifier an interface class so that it can be implemented (#55494 (comment)).

The resources.json will then get an annotations field (it can have more than one annotation), and each annotation will get a name for example JClassIdentifier and a map of all fields.

[mosuem]

The code for replacing ResourceIdentifier would be

interface class RecordReference {
  // ignore: unused_field, this field will be recorded by the SDK.
  final Object? _metadata;

  const RecordReference([Object? metadata]) : this._metadata = metadata;
}