Description
openedon Jun 15, 2021
One thing that can take a lot of time and is prone to missed issues is unifying APIs across languages. I think we could better solve this by providing a view of the raw language tokens - applying some rules to normalize token types (e.g. methods, properties) - and allow showing them side-by-side from 2..n languages (as many as a monitor(s) can practically fit).
For example, if tokens were presented like so in a package-then-namespace-then-class (or global method) case-insensitive order, we could probably get through unification reviews more quickly - maybe even automate them:
ClassA.Method0(param0: Foo, param1: Bar)
ClassA.Method1()
ClassA.Property0 # or get_Property0
GlobalFunc0(param0: Baz)
Class, method, property, and parameter names should all be the real thing of course, since parameter names often matter. Language normalization transforms could change, for example, Java's get_foo
pattern into foo
, or .NET's Foo
property into get_Foo
. Most languages use the list
prefix for enumerables while .NET uses Get
, so normalize those somehow (maybe for sorting only, use "list" but still display "Get"). We might even consider eliding common parameters - showing an error when APIs don't abide - like Go's ctx: Context
, .NET's CancellationToken cancellationToken
, etc.
In this way, we end up with a view like (discrepancies intentional to show how this could be helpful):
.NET | Java | JavaScript | Python |
---|---|---|---|
ClassA.Foo(bar: Bar) | ClassA.foo(bar: Bar) | ClassA.foo(bar: Bar) | |
ClassA.Bar() | ClassA.bar(bar: Bar) | ||
ClassA.baz() | ClassA.baz() | ClassA.baz() |
Metadata
Assignees
Labels
Type
Projects
Status
🤔 Triage
Status
No status