-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
refactor: clean core experiment #938
Conversation
@0xSage, (abstract) classes are available at runtime, while interfaces are compile-time only. We built the core SDK to allow the Extension Builder and App to inherit/use it, mostly at runtime. There are a bunch of type checking to let app can poll correct extensions to invoke their function at runtime. let x: any;
// IThreadExtension is an interface
if (x instanceof IThreadExtension) { // Error: 'ThreadExtension' only refers to a type, but is being used as a value here.
}
// ThreadExtension is an abstract class
if (x instanceof ThreadExtension) { // OK
} |
Yes, I realized this while refactoring |
I'm really not sure |
@louis-jan our codebase has evolved significantly since I did this experiment (kudos to you and team). What pieces of this experiment should actually be merged in? What about refactoring types and interfaces into something like: /types
/assistant
assistant.ts (for types, enums, globals)
assistantInterface.ts (for interface definition)
index.ts (simply exports types & interfaces) such that (s.t.): It may seem redundant but it decouples interfaces from extensions (and makes dep path clearer). For any changes worthy of being incorporated, I'd like @hieu-jan to take over from here. |
@0xSage The types refactoring is neat. Please merge, also decouples interfaces, totally agree. |
Closing this PR in favor of #966 |
This PR (originally an experiment) refactors types into clean entities