Skip to content
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

Behavioral Attributes and Analyzers #293

Open
Entomy opened this issue Jul 29, 2021 · 1 comment
Open

Behavioral Attributes and Analyzers #293

Entomy opened this issue Jul 29, 2021 · 1 comment
Labels
🏗 Architectural Related to architecture of the code 💢 Difficult This issue is expected to be difficult to resolve 🛠 Enhancement New feature or request 🛡 Hardening Hardening up code through defensive programming techniques
Milestone

Comments

@Entomy
Copy link
Owner

Entomy commented Jul 29, 2021

Understandably so, downstream wants to have access to performance and behavioral characteristics of the code in these libraries. One of the common approaches to addressing this is putting the asymptotic time complexity, and possibly space complexity, into the documentation. This has a number of issues I don't find satisfactory. First is that most editors won't show the remarks, where this would be documented, on hover or IntelliSense. This requires downstream to regularly pull on the online docs, even though the docs are built into the nuget package. This is considered too disruptive to workflow to be acceptable, especially as easily swapping implementations is a core design for both Collectathon and Stringier. Secondly is that putting information like that into documentation prevents any kind of computer assistance involving it. Thirdly is that asymptotic complexity has some issues due to it being so incredibly abstract, and I don't feel it's the best way to describe the critical things it needs to.

What I believe is the best way to tackle this is to describe a set of behavioral attributes which can annotate the necessary behaviors. Critically, no part of this design prevents asymptotic complexity annotations, so the two can be used mutually in the future.

The idea is to use a similar approach to the nullability analyzers, for things like internal buffer resizing, new node linkage, and more. These would then be able to clearly describe what is happening, and provide something for Roslyn Analyzers to work with, performing flow analysis on the behaviors. Best of all, the attributes show up for downstream, and they can use the same analyzers as well. Those who aren't interested in this information can freely ignore it.

@Entomy Entomy added the 🛠 Enhancement New feature or request label Jul 29, 2021
@Entomy Entomy self-assigned this Jul 29, 2021
@Entomy Entomy modified the milestones: v5.0, v6.0 Jul 29, 2021
@Entomy Entomy removed their assignment Aug 2, 2021
@Entomy Entomy added 💢 Difficult This issue is expected to be difficult to resolve 🛡 Hardening Hardening up code through defensive programming techniques 🏗 Architectural Related to architecture of the code labels Aug 2, 2021
@Entomy
Copy link
Owner Author

Entomy commented Aug 16, 2021

I want to include exceptions as part of this. A number of behaviors involving exceptions should be looked at beyond just tracking what is thrown.

While people can't seem to agree on how exceptions should be used, I'm personally very fond of only ever using them for unhandleable situations, which means handlers should be disallowed. This could be enforced by analyzer, and people who don't want it can turn it off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏗 Architectural Related to architecture of the code 💢 Difficult This issue is expected to be difficult to resolve 🛠 Enhancement New feature or request 🛡 Hardening Hardening up code through defensive programming techniques
Projects
None yet
Development

No branches or pull requests

1 participant