Skip to content
New issue

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

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

Already on GitHub? # to your account

Handle private properties in the compiled model #33409

Merged
merged 1 commit into from
Apr 4, 2024
Merged

Conversation

AndriySvyryd
Copy link
Member

Add full support for service properties
Use a consistent pattern for unsafe accessors
Store the unsafe accessor names in an annotation
Refactor the different mechanisms for tracking variables in the generated code into a single bidirectional dictionary

Fixes #29761
Fixes #24904
Fixes #24900

public static string GetUnsafeAccessorName(MemberInfo member)
{
StringBuilder stringBuilder = new();
stringBuilder.Clear().Append("UnsafeAccessor_");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this our naming convention, or a convention recommended from somewhere else?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there's a specific recommended naming convention for unsafe accessor (see API docs with samples), this is also what I used on the query side when generating these.

No strong feelings of course (this is all "internal" generated code), it just seemed like a code idea to identify what these methods are etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just noticed that it generates very long names. Not a big deal, but given the size of generated code has been an issue it was something that occurred to me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just made it consistent with what query generates. The idea is to have a unique name that still means something. If Shay agrees we can just use the member name + uniquefier to keep it short.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, am fine with whatever - remember this is just generated code so nothing's very important here (except for uniqueness).

{
if (assignmentKind is not SyntaxKind.SimpleAssignmentExpression)
{
throw new NotSupportedException("Compound assignment not supported");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hard-coded string?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is from Shay's PR, I was reading this as "not implemented", we could handle compound assignments by calling the getter and then the setter

Add full support for service properties
Use a consistent pattern for unsafe accessors
Store the unsafe accessor names in an annotation
Refactor the different mechanisms for tracking variables in the generated code into a single bidirectional dictionary

Fixes #29761
Fixes #24904
Fixes #24900
@AndriySvyryd AndriySvyryd merged commit 7213003 into main Apr 4, 2024
7 checks passed
@AndriySvyryd AndriySvyryd deleted the Issue29761 branch April 4, 2024 05:02
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
3 participants