Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shall we have IKeyed interface in M3? #142

Closed
enikao opened this issue Jun 30, 2023 · 1 comment
Closed

Shall we have IKeyed interface in M3? #142

enikao opened this issue Jun 30, 2023 · 1 comment

Comments

@enikao
Copy link
Contributor

enikao commented Jun 30, 2023

In our M3, both Language and NamespacedEntity have a property key: String.
We could introduce a common interface HasKey in M3.

LIonWeb Java has such an interface. It helps with finding all keys in a language, and check their conformity with spec.

On 2023-06-30, we decided NOT to have such interface.
Any concrete implementation is free to chose HasKey (or any other variant) as a way to implement the M3.

@enikao enikao changed the title Shall we have HasKey interface in M3? Shall we have IKeyed interface in M3? Jul 10, 2023
@enikao
Copy link
Contributor Author

enikao commented Jul 10, 2023

On 2023-07-07, we decided to rename NamespacedEntity to IKeyed with a property key: String. Language implements IKeyed. This effectively establishes an interface HasKey, with slightly different name.

Rationale: IKeyed name is symmetric with the existing interface INamed (#86).
We remove the notion of namespace as element in M3 (#146).

Side effect: Everything inside M3 realizes IKeyed. In this sense, something like ILanguageMember might be more suitable. However, such a name would be too similar to LanguageEntity (#147).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant