Proposal: user defined attributes

dennis luehring dl.soluz at gmx.net
Mon Mar 19 05:42:19 PDT 2012


exactly my point - thx

Am 19.03.2012 13:31, schrieb Steven Schveighoffer:
> On Sun, 18 Mar 2012 04:03:29 -0400, Walter Bright
> <newshound2 at digitalmars.com>  wrote:
>
>>  On 3/17/2012 10:01 PM, F i L wrote:
>>>  Walter Bright wrote:
>>>>  My impression is it is just obfuscation around a simple lazy
>>>>  initialization
>>>>  pattern.
>>>>
>>>>  While I can see the abstraction usefulness of compile time attribute
>>>>  metadata,
>>>>  I am having a hard time seeing what the gain is with runtime
>>>>  attributes over
>>>>  more traditional techniques.
>>>
>>>  I'm not sure exactly what you mean by runtime attributes. Do you mean
>>>  the
>>>  ability to reflect upon attributes at runtime?
>>
>>  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#.
>
>>  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).
>
> 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




More information about the Digitalmars-d mailing list