Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[DYN-1682]: Improve node warning, autocomplete and Node2Code behavior with class name conflicts #10558
[DYN-1682]: Improve node warning, autocomplete and Node2Code behavior with class name conflicts #10558
Changes from 6 commits
e70e13a
d5b0161
360f878
91f6724
714bae8
17761b6
e2a341d
c773812
5cb38ca
defaddc
30a8d62
206ee14
b1370bb
a5575f0
f43667b
0f8b3cf
2e6be14
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just double checking - this should always be
0
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we want the most derived class in that list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does
internal
work here?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, since this method is defined in
ProtoCore
but now being used inDynamoCore
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand this is being used by dynamo core - we also can use the internalsVisibleTo attribute to expose internal members to other assemblies which we own.
We should develop this principal further, but a few points.
Is this method something that should be used externally by integrators? Is there a compelling reason to make it part of the API? An interesting use case? A workflow that cannot be implemented without it?
If not, then what is the benefit?
If yes, then great, let's add documentation to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we made a decision on going forward with reducing the API surface of DynamoCore, DynamoCoreWpf etc. by continuing to expose them as our public API or are we deciding on keeping them as-is and making them internal and having a separate API layer for public consumption (based on your RFC)?
Whatever is the strategy, I think then we should come up with certain coding guidelines before we continue to make PR's. Going by the RFC again, it sounds like none of ProtoCore should be part of the API and we should surface just the AST's publicly. I'll make this method internal as well for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we have made no decision -very much welcome those discussions - there are many options.
Thanks for addressing this, I don't think we can stop all work before we entirely decide this - but what I am suggesting is that we proceed conservatively until we do so.
I think it's likely we will find that some users are already using ProtoCore, and other binaries we didn't consider fully as APIs.
For example, the Civil3d integration has very specific interactions with callsites and trace, I am not 100% what APIs that team uses to control and redirect trace but I guess it is in protocore.