You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #1960 we've been having a debate about the proper design of the API for initializing virtual objects (please see that issue for the discussion thread leading up to this). However, that issue was actually just a PR for some updates to the documentation, hence not really the right place to try to resolve the API design question. The correct issue to do that is right here.
The text was updated successfully, but these errors were encountered:
To summarize: @erights is displeased with two aspects of the current design: (1) contamination of the developer's namespace for methods on their virtual objects by having initialization flow through a special method named initialize, and (2) magically tinkering with the object that defines the virtual object's behavior by deleting the special initialize method from it so that it won't be exposed to holders of references to the virtual object.
In a conversation with @warner this afternoon, he suggested we might mitigate the namespace concern by keying the initialization method with a symbol available from the makeKind function, e.g., [makeKind.initialize] or some such. This would not address the concern about having a magic method, but wouldn't be a name that a virtual object developer would want to otherwise use.
In #1960 we've been having a debate about the proper design of the API for initializing virtual objects (please see that issue for the discussion thread leading up to this). However, that issue was actually just a PR for some updates to the documentation, hence not really the right place to try to resolve the API design question. The correct issue to do that is right here.
The text was updated successfully, but these errors were encountered: