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