dotnet: how to represent getter/setters

[williballenthin]

dotnet may emit accessor/mutators (getter/setters) for some fields rather than direct field access. how do we recognize and emit these features?

[williballenthin]

need concrete example

[williballenthin]

suspect that getter/setter is identified via method def flag

[williballenthin]

do we need a few feature for instance property access? do we reuse offset?

e.g.

- property: System.Net.FtpWebResponse.statusCode
- offset: System.Net.FtpWebResponse.statusCode

[mike-hunhoff]

[mike-hunhoff]

for imported classes we may be able to identify getter/setter by signature type; specifically if the signature is of type Property.

[williballenthin]

wow getters can have parameters? makes me think we might want to emit both API and property features.

…

On Apr 7, 2022, at 11:06 AM, Mike Hunhoff ***@***.***> wrote:  for imported classes we may be able to identify getter/setter by signature type; specifically if the signature is of type Property. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[mike-hunhoff]

example:

C#:

ftpRequest.KeepAlive = false;

IL:

IL_0000: callvirt  instance void [System]System.Net.FtpWebRequest::set_KeepAlive(bool)

[mike-hunhoff]

I like the idea of adding new property and field features. it may also be useful for users to specify whether a property/field is read/written.

detection should be fairly straightforward. non-public fields are accessed via properties, which we can identify using the .NET metadata. public fields, from my understanding, are accessed directly using CIL instructions stfld/stsfld, ldfld/ldflda/ldsfld/ldsflda.

I'm unsure how to represent read/writes to properties/fields if we decide to go that route.

(1) use / notation:

- property/get: System.Net.FtpWebRequest::KeepAlive

(2) use the get_ and set_ nomenclature seen in dnSpy:

- property: System.Net.FtpWebRequest::get_KeepAlive

(3) don't facilitate read/write access:

- property: System.Net.FtpWebRequest::KeepAlive

I lean towards 3 simply because I can't think of an example where it would be useful to specify read/write access.

[williballenthin]

do you think its important to differentiate properties from fields?

[mike-hunhoff]

No, I think it'd be fine to choose one feature term to represent both. If I were to choose one I'd prefer field or to reuse offset as you suggested.

[mr-tz]

I think (3) is sufficient for now. I'm not a fan of the other syntax proposals.

[mr-tz]

I've changed my mind and think differentiating between read and write would be useful.

1.

- property/get: System.Net.FtpWebRequest::KeepAlive
- property/set: System.Net.FtpWebRequest::KeepAlive

2.

- property/read: System.Net.FtpWebRequest::KeepAlive
- property/write: System.Net.FtpWebRequest::KeepAlive

3.

- property/r: System.Net.FtpWebRequest::KeepAlive
- property/w: System.Net.FtpWebRequest::KeepAlive

I'm in favor of 2. since it's clear and appears most versatile (across languages/formats).

[mike-hunhoff]

closed by #1168