Matan:
I'm not sure that I follow the phrasing, as you don't declare any of
these—they are objects that you get from queries of the API.
You do not create or initialize them—they are just returns
from queries.
Andy:
So you use the API to
return an object or definition element?
Matan:
Yes. It would be easier to start from the bottom. You have structs
representing struct types, you have structs representing method
objects, and since they and events are extensible entities and
defined over different locations in your program (is only, etc),
they have multiple definition elements. In the case of structs, a
struct is composed of one or more struct layers. Methods represented
by an rf method object represents multiple method layers. Each of
these definition elements links to one of these.
Andy:
So, one definition element links to one of these defining entities?
Matan:
Yes. The only thing that is common to all is that they are tied to a
source location—a file and line. It is perhaps too abstract to
be useful, but it is common to all of them.
Andy:
Perhaps we can condense this description down into a few sentences
that can be a lead-in to section 30.3.1.3—or perhaps is the
last paragraph of the last section. Although perhaps that is
discussing things such as lists which can't been extended. Perhaps
the best place for rf_definition
element and definition layers is at the very beginning of 30.3.1.3,
ahead of the bullets describing the methods.
Matan:
OK. I can try to find the right spot to inject the clarification.
The main point is that the definition element is just an abstraction
of those definition objects represented in layers.
Andy:
Other comments regarding this section of the clause? I found it one
of the more confusing areas.
[Silence]
Andy:
Again, this is on pg 398 of the new doc. Is there anyone apart from
Matan who has used the reflection facility?
Mark:
I have used it—no rf_definition_elements.
Andy:
Have you had a chance to look at this section?
Mark:
I looked at it in a “shallowish” level. It look
reasonable.
Andy:
So enough info to implement from?
Mark:
Yes.
Andy:
I'll open the floor to other areas of the reflection document. There
are 11 other edits being reviewed. The next version will be in the
full LRM, so it will be
the last chance to focus just on this.
[Silence]
Andy:
Don't all speak at once.
Darren:
I have read the document as I resolved most of the issues, but I
haven't used it in anger. It looked okay, but I can't say if it
would be enough for an implementer—it looks okay.
Andy:
Anything else?
Matan:
Just reading the API
spec—it is quite formal with respect to the implementer. There
is not much loose here—it is all about the structure of the
program which is defined throughout the LRM. This is more or less
straightforward model of the rest of the declarative part of the
language. It models the rest and as such is well defined for the
potential user of the reflection API.
For understanding of how to get things done from this part of the
spec is very hard—perhaps we might enhance it.
Andy:
In the example section?
Matan:
Yes.
Andy:
The example section is much more useful for the user and how to get
information from the type interface, and how to walk through the
meta objects and get information.
Matan:
The idea of meta-programming is confusing, but you can quickly get
the hang of it with a good example.
Andy:
There are several areas where it needs tidying up—it has
Specman command lines shown. It needs making more generic.
Mark:
In the original section, unsafe was confusing. When do I have to
avoid it and when it is impossible? Perhaps it should be in the
example section, as it is unclear what the user should do—might
be clear for the developer.
Andy:
It is possible that we could illustrate the use of unsafe in the
example section.
Mark:
The example uses it, but doesn't explain the algorithm it uses.
Andy:
The example uses it—several in fact, but it doesn't say what
it does. Mark—the example should say why we are using
it?
Mark:
That would help.
Matan:
It is somewhere else in the LRM?
Andy:
Yes? I'll look it up.
Matan:
With meta-programming you are not relying on the static type system
of the language. You have an object which you don't know the type
of—to manipulate it you must cast.
Andy:
It's like casting in C.
Matan:
Its equivalent to the C++ cast. What gives the type is the context.
The type of the article gives what cast is used.
Andy:
We can add this info for the '08 doc. Any other discussion for
reflection?
[Silence]
