search

sigmundch / DEP-member-interceptors

little experiment of using barriers to implement observability
4 stars 4 forks source link

syntax debate: annotations vs specialized syntax #12

Open sigmundch opened 9 years ago

sigmundch commented 9 years ago

The design doc includes a long discussion about syntax alternatives.

Let's use this issue to keep the syntax discussion in one place.

sigmundch commented 9 years ago

One concern I raised in the doc is that by using annotations we will add semantic meaning to metadata in the language. Turns out there are two aspects to this concern, but I mainly addressed one in the doc:

  1. users will see the semantic meaning
  2. the VM runtime needs to be aware of the semantic meaning: this can make metadata expensive in the VM

@gbracha - is (2) your main concern?

In the doc I mainly talked about (1). I believe it is not an issue because frameworks already do this today. Mirrors expose annotations and frameworks give it a semantic meaning.

As for (2), it would be great to understand what the runtime does today and how much extra cost we are talking about. In particular, is the runtime evaluating the const expressions to build the annotations already? If so, the extra cost we are adding is basically and instance-of check (the cost of applying interceptors will be there with the other syntax too). Could we measure this and see who much of a cost this is? I expect that snapshots could store this information efficiently too, since it can all be computed statically.

sigmundch commented 9 years ago

Issue #11 brings up an important question: are interceptors part of the public API or a hidden implementation detail.

If it's the former, then annotations might not convey that intuition and using a dedicated syntax might be the way to go.