Design+implementation for handling boolean properties

[davidmorgan]

Copied from a review reply on #3

On the one hand we want to preserve uniformity, so for example it should be possible to say "is static" and have that mean something in any place in the model where it makes sense.

On the other hand it is good to have the API statically encode knowledge about what properties are available.

So probably we end up with a family of Properties types, compatible on the wire but adding knowledge about validity via the extension types.

[jakemac53]

This is also about how to represent what "kind" an object is. A class, function, getter, etc.

[davidmorgan]

Right.

My current idea is to think of properties as "capabilities", i.e. that they tell you about something you can do with the entity.

In some cases that "something you can do" is that you can interpret the entity using a particular extension type; or, equivalently, that it complies with a particular fragment of JSON schema.

In that case they would come with "is/as" methods, so for example

for (final function in members.map((m) => m.asFunction).nonNulls) {
  ...do something for all functions... 
}

I guess what we end up with is, in OO terms: the "kind" is the concrete type, and the properties describe the interfaces that it implements.

From a schema point of view we would have a oneOf, and a property that selects between them. So for example Member has {"kind": "member"} in its schema.