Entomy / LibLangly

The combined Langly runtime
https://entomy.github.io/LibLangly/
33 stars 7 forks source link

Behavioral Attributes and Analyzers #293

Open Entomy opened 3 years ago

Entomy commented 3 years ago

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 commented 3 years ago

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.