On 2012-03-19 13:31, Steven Schveighoffer wrote:
On Sun, 18 Mar 2012 04:03:29 -0400, Walter Bright
I mean there is modifiable-at-runtime, instance-specific data.
I don't think we should go this far with attributes. If you want to
store instance-specific data, we already have a place for that. I
haven't been exactly groking all of this thread, but I understand what
attributes are useful for having used them quite a bit in C#.
I agree.
Again, I am just not seeing the leap in power with this. It's a
mystery to me how a user defined "attribute class" is different in any
way from a user defined class, and what advantage special syntax gives
a standard pattern for lazy initialization, and why extra attribute
fields can't be just, well, fields.
The advantage is it hooks you into the compiler's generation of metadata
and runtime type information (i.e. TypeInfo). It basically allows you to
describe your type in ways that the compiler doesn't natively support.
It's purely a type-description thing, I think it has nothing to do with
instances.
The serializable example is probably most used because it's one of the
most commonly used attributes in C#/Java. Given that neither has
templates, the impact is somewhat greater than in D, but I believe Jacob
has quite a bit of experience with serialization of types given that he
wrote a serializer for D, so he would be the one I'd ask as to why it's
better. I think another great example is data you can pass to the GC (if
we ever get precise scanning).
For the serialization example I think it's mostly a syntactic
enhancement. It would also be an enhancement when accessing the attributes.
class Foo {
int a;
@NonSerialized int b;
}
class Bar
{
int a;
int b;
mixin NonSerialized!(b);
}
The advantage the attribute has is:
* Better syntax, more readable
* Shows up in the documentation of "b".
* Can be repeated on several fields (with the mixin you can only mixin
"NonSerialized" once)
* Easier to access the attribute
* No information is added to the type itself. It would be added to the
metadata of the type, i.e. TypeInfo
But I see many other cases where attributes would work better than mixins.
In a previous life, while using C#, I created a "scripting" system that
used objects to define what methods were run during certain test
processes (the application managed the automated testing of servers
remotely). The entire script was constructed based on an xml file, and
the library that edited/built the script had no access or knowledge of
the types it was constructing, it used pure reflection to do everything.
The cool thing (in my mind at least) was, I had a script builder
application which "opened" the executable to find all the scripting
objects. It did not need to be recompiled, nor did it directly link with
a library having the script objects, because it used reflection to
determine everything I needed. Some specific attributes weren't
available in reflection, so I just added some user-defined attributes,
and in that way, I was able to affect the metadata to pass information
to the script building application.
I think also you can make code more readable and easier to write with
attributes, because you can specify/convey information rather than
interpreting or making assumptions, or inventing types that have nothing
to do with the way the type works.
For example, you could do something like:
struct noSerInt
{
int _val;
alias this _val;
}
struct X
{
noSerInt x; // clue to not serialize x
}
This is extra complication which is not needed while using an instance
of X *except* when serializing it. I think it's cleaner to put this
information into the metadata instead of having to re-implement int.
Compare to:
struct X
{
@noSer int x;
}
Where you can safely ignore the @noSer attribute for most intents and
purposes.
I think that the sole purpose of attributes is compile-time generation
of compile and run-time query-able data. Nothing else really makes sense
to me.
-Steve
Very well explained.
--
/Jacob Carlborg
