Re: [Vala] Custom attributes/decorators

[Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>]

2009/4/22 Vlad Grecescu <b100dian gmail com>:
> On Wed, Apr 22, 2009 at 3:54 AM, Christian Hergert
> <christian hergert gmail com> wrote:
> > Hi Folks,
> >
> > I'm curious about how people feel about adding a feature for custom
> > attributes/decorators that can be used for meta-programming.  If that
> > doesn't make sense, let me show an example of what I would like to
> > make possible.
> >
> > ...
> >
> > Does this sound interesting to anyone?  Should I file an enhancement
> > request?
>
> Well it surely does to me. However, which approach would benefit the most?
>
> Custom attributes could be
> a. available at compile-time. A plugin/gmodule for valac would be used to
> process them (generate code, in your case).
> b. available at runtime, the Flex way. The mxmlc just stores your custom
> attributes which can be inspected at runtime with describeType's XML [1][2]
> c. available at runtime, the Java way. The custom attributes are just
> interfaces from your code, further present in
> type.getAnnotations/method.getAnnotations

Just a nit-pick; Java annotations are not available at runtime by
default. One has to specify a "retention policy" of how the
annotations are made available, there are three possibilities:

CLASS: "Annotations are to be recorded in the class file by the
compiler but need not be retained by the VM at run time"
RUNTIME: "Annotations are to be recorded in the class file by the
compiler and retained by the VM at run time, so they may be read
reflectively."
SOURCE: "Annotations are to be discarded by the compiler."

I think it would make sense to have something similar for custom Vala
attributes, like:

DATA: Not available at runtime, but stored inside the TEXT segment of
the generated binary object files (if this even makes sense && is it
possible with gcc?). The use case here is some static analysis of the
binary files
RUNTIME: Somehow attached to the enclosing GObjectClass or something..?
SOURCE: Not available at runtime, but expands to a source code
template in some way like Christian suggests

Of course one need not implement all policies in the first go, but
leaving room for policies could be a great boon in the long run.

Just my 0.02€. Cheers,
Mikkel