This repository has been archived by the owner on Feb 4, 2025. It is now read-only.
Consider mimicking type hierarchies in our extension types. #103
Comments
jakemac53
added a commit
that referenced
this issue
Oct 21, 2024
Closes #100 - Adds `model` field to AugmentRequest, with implementations to pass it (although, these use a host side query). - Expose the `hostService` from the `MacroHost` (used to do the query) - Adds a `Model` parameter to all macro methods (typed as `Object` for right now for most of them, as we don't have better types yet). - Make all fields on AugmentRequest required (this simplified implementations, but lmk if you want me to revert this). - Rename the `Model.qualifiedNameOfMember` extension to `qualifiedNameOf` generalizing and fixing it: - Now it actually does what it says 🤣 (it used to return just the qualified name of the type the member is declared in I think?), there was in any case no way to represent members with qualified names, see #101 which adds that. - It now throws for anything other than types, since they can't be referenced - It just accepts a `Map<String, Object?>` now which is the only thing we can generalize on for the moment, but see #103 for one possible workaround. - Fixes up tests and removes expected request/response from the client for the model
jakemac53
added a commit
that referenced
this issue
Oct 29, 2024
Towards #103 Adds an `implements` list to `Definition.clazz`, which: - Replaces the default `implements Object` and instead lists all the implemented types (which transitively gives `Object`). - Adds all inherited properties and associated code to the constructors and schemas - Does not re-generate getters, these are inherited via `Implements` I also added a base type `Declaration` because it is both useful and also serves as an example usage. I think one good follow-up would be to add `is<Type>` and `as<Type>` getters to anything which is implemented by another type, for each of the types which implement it. We at least need some mechanism for down casting extension types to their known subtypes. One tricky part with that though is ideally we don't want to inherit those methods in the subtypes, because they won't all make sense?
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Specifically the idea here would be to add an
String? implementsoption to the generator for class definitions. If present, the extension type would implement the given type.All properties from that implemented type would be copied into the extension types constructors and schema. The members would not be regenerated though, since they would come with the implements clause.
Specifically the first thing we would use this for is to create a
Declarationtype, which has the shared properties of all declarations. And then the API for getting a qualified name for a node in a model could beQualifiedName? qualifiedNameOf(Declaration declaration), as opposed to needing specialized methods for each declaration type, or making you explicitly call.nodeand accepting a Map type (I have a separate change to do the latter out pending).I am not exactly sure how to represent these in the schema in the best way (union types, and copy the "inherited" members into each schema type?).
The text was updated successfully, but these errors were encountered: