Hi Jean-Francois,
I really like the idea of generalizing (and defining) the attribute
framework that we already have in place for ROOT. For me, the goals are
* versatility
* precision
* readability
Let me go through the different suggestions I have:
- //[]' vs //@
I understand that your suggestion comes from C#; I would prefer to use
the Java version instead, which I find more readable because of less
nesting: it does not require a surrounding set of [] which are not
strictly necessary syntactically. The //[ tag interferes with ROOT's
current set of "attributes"; yet another reason why I prefer to use //@.
- I would like to have namespaces prepended to the keys (attribute
names) as a requirements, to prevent clashes between e.g. future
versions of reflex and user code.
- Sometimes the attribute location is a convenient way to define the
attribute's target, but e.g. for parameters or functions' return values
it is not. I like the javadoc / doxygen way of specifying a target.
- To extend this, I would propose a generic targeting syntax, where one
_can_ specify the target of an attribute by giving its "type type" and
its signature / name.
- I would like to keep compatibility with ROOT's attributes in that they
should be behind the semicolon for data members, starting at the same
line; for everything else they could be in front.
That boils down to the following syntax suggestion:
//@TYPE.TARGET:NS.KEY(VALUE)
- TYPE is optional, one of {Member,Type,Scope,Param,ReturnValue}.
- TARGET is optional, its the name (and optionally signature) of a
Reflex entity
- NS is the namespace prefix for the attribute name, e.g. reflex
- KEY is the name of the attribute, and VALUE its value.
So this
//@Member.MyFunc(int,void):ROOT.doc("a func")
and this
//@ROOT.doc("a func")
would be identical as long as the latter is right in front of the
function declaration of MyFunc(). It would also allow e.g.
//@ROOT.doc("a func")
//@Param.a:ROOT.doc("input")
//@Param.b:ROOT.doc("output")
//@ReturnValue:ROOT.doc("nothing")
void MyFunc(int a, int& b)
Now - I can suggest this because I don't expect to be working on it any
time soon :-) But it would be nice if we can come up with a syntax that
is extensible in the future so some of this can be covered.
Does any of this make any sense to you?
Cheers, Axel.
On 2008-01-22 21:41, Jean-Francois Bastien wrote:
>> Correct.
>>
>> The first MS URL you sent talks about using attributes to
>> indicate what features an object of some class has. The
>> example is a class stating it is serializable. This use maps
>> to interfaces well. If the object can be dynamic_cast'ed to
>> an "ISerializable" interface then you know it provides the
>> needed features and you have a way to get them.
>
> I agree with you, but our code base already uses interfaces extensively.
> There is a need for annotations that interfaces can fill to some extent
> but which is much more troublesome and much less flexible. One important
> use is for tools: ideally they don't have instances of the types to work
> with, and they don't even know the types they're going to work with,
> it's the types that tell the tools what can be done with them. With
> interfaces I'd need to modify and recompile my tools for each new
> interface I create.
>
> The user code further needs to have member types deriving from an
> interface, even if it just wants a simple double as a member. With
> introspection and annotations the member can be a double and publish
> certain things without being a class.
>
>
> JF
>
>
Received on Thu Jan 24 2008 - 17:33:41 CET