API writability and the editor

  • Article

Steve Clark talked about usability of APIs, and a snag some users hit when writing against ADO.NET, and some possible ways to help. It should come as no surprise that I think the ideal solution for this problem relies on the editor. (Because my team makes the editor!)

Today, if you're browsing a completion list in C#, there are some things you can find methods, properties, and fields on an object. If you know the icons, you can know the accessibility, as well.

There are some things you can't figure out as easily:

  • inherited interfaces
  • the base class, if any
  • indexers
  • implicit & explicit casting operators
  • other operators

In a previous blog, I talked about “interface property” which will help with the first item. 

In the C# IDE design meetings, we talked about enhancing intellisense to give you this sort of information. We didn't find a user model that we really liked, the implementation costs for what we thought of were way to high to justify the work, and we were running out of time. So, nothing came of it in Whidbey. 

The best we came up with was this. Suppose you have an object 'x', with an indexer 'this[int i]'. In the member list for x, we could show the indexer:

    x. | F() |
| this[int i] |
| etc ... |

If you select the indexer, we remove the '.' and insert '[]', placing the cursor between the brackets. We could also do similar things with interfaces ('as IFoo') and others. 

Another feature we added in Whidbey was the “metadata as source“ view. With it, you can explore the public definition of a class in a form that we think is very comfortable for you (“Elvis is code focused“). 

In Steven's case, users didn't realize they should iterate with IEnumerator (foreach). Suppose 'IEnumerator' showed up in the member list? Would users figure it out then?

He also talked about classes being able to have tasks on them. We're not there yet, but expansions are a step in the right direction. If you look at the way VB has built expansions, they're working on tasks. C# has built them as a way to speed typing of common constructs. Same technology, different users.