View mode: basic / threaded / horizontal-split · Log in · Help
March 18, 2012
Re: Proposal: user defined attributes
On 18 March 2012 03:48, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/17/2012 6:39 PM, Manu wrote:
>
>> I'm sure C# already answers all these questions. It has precisely the
>> same set
>> of issues associated.
>>
>
> C# doesn't have RAII, immutable, nor the notion of threadlocal/shared
> types.
>

C# has immutable. How does RAII cause a problem here?
The threadlocal/shared stuff shouldn't be a problem, since the attribute
instances are contained by the class its self, it just has the same
locality properties. Can you imagine a case where that would be problematic?
March 18, 2012
Re: Proposal: user defined attributes
On 3/17/2012 7:04 PM, Manu wrote:
> On 18 March 2012 03:48, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
>     On 3/17/2012 6:39 PM, Manu wrote:
>
>         I'm sure C# already answers all these questions. It has precisely the
>         same set
>         of issues associated.
>
>
>     C# doesn't have RAII, immutable, nor the notion of threadlocal/shared types.
>
>
> C# has immutable.

No, it does not.

> How does RAII cause a problem here?

Generally, supporting it tends to permeate the semantics of the language. Simple 
things like copying a value onto the parameter stack entail all kinds of issues.

> The threadlocal/shared stuff shouldn't be a problem, since the attribute
> instances are contained by the class its self, it just has the same locality
> properties. Can you imagine a case where that would be problematic?

If it's shared, how is access to the data controlled if multiple threads access 
it at the same time?
March 18, 2012
Re: Proposal: user defined attributes
On Sunday, 18 March 2012 at 01:48:07 UTC, Walter Bright wrote:
> On 3/17/2012 6:39 PM, Manu wrote:
>> I'm sure C# already answers all these questions. It has 
>> precisely the same set
>> of issues associated.
>
> C# doesn't have RAII, immutable, nor the notion of 
> threadlocal/shared types.

It has threadlocal using the [ThreadLocal] attribute which gets 
implemented by the compiler.

In C#, all attributes live inside the TypeInfo/MethodInfo/etc for 
the class/struct/method/field/parameter. I don't see this being a 
problem. I can't think of good use cases where an 
attribute/annotation should be per-instance at all, particularly 
with the compile-time power that D has, whereas C# does not have 
any. Honestly, most uses of attributes in D would be done at 
compile-time, and I think that's acceptable until/if runtime 
reflection is put in. If it is needed, it can live inside 
TypeInfo/MethodInfo, but is (imo) absolutely not needed on a 
per-instance basis. This is the job of fields or interfaces.
March 18, 2012
Re: Proposal: user defined attributes
On 3/17/2012 8:04 PM, Kapps wrote:
> It has threadlocal using the [ThreadLocal] attribute which gets implemented by
> the compiler.

That's a storage class, not a type constructor. In D, threadlocal/shared is a 
difference in the type.

> In C#, all attributes live inside the TypeInfo/MethodInfo/etc for the
> class/struct/method/field/parameter. I don't see this being a problem. I can't
> think of good use cases where an attribute/annotation should be per-instance at
> all, particularly with the compile-time power that D has, whereas C# does not
> have any. Honestly, most uses of attributes in D would be done at compile-time,
> and I think that's acceptable until/if runtime reflection is put in. If it is
> needed, it can live inside TypeInfo/MethodInfo, but is (imo) absolutely not
> needed on a per-instance basis. This is the job of fields or interfaces.

I also do not get why per-instance attributes even exist, as I agree that's what 
fields are for.
March 18, 2012
Re: Proposal: user defined attributes
Walter, how do you feel about the compile time
annotation list?

I looked at implementing it, and it is a little
more involved than I thought (mainly in changing
parse.c to treat @ things as more than just storage
classes), but still not terrible.
March 18, 2012
Re: Proposal: user defined attributes
Walter Bright wrote:
> I also do not get why per-instance attributes even exist, as I 
> agree that's what fields are for.

Attributes are per-type (type properties, methods, etc), not 
per-instance, and only accessible (in C#) through type reflection 
(to my knowledge). According to 
http://msdn.microsoft.com/en-us/library/z919e8tw(v=vs.80).aspx 
attribute objects aren't constructed until reflected upon. I 
think attributes in combination with D's templates would be very 
useful:

    @attribute class Cool
    {
        bool isCool;
        this(bool cool)
        {
            isCool = cool;
        }
    }

    class CoolClass(bool cool)
    {
        @CoolType(cool);
        int type;
    }

    void main()
    {
        auto cc = new CoolClass!true();
        if (cc.type@Cool.isCool) { // (new Cool(true)).isCool
            // Do something cool...
        }
    }

Or, if @attributes could be applied to *any* type (enums, 
structs, variables, etc..), we could write this more simply:

    @attribute bool isCool;

    class CoolClass(bool cool)
    {
        @isCool = cool;
        int type;
    }

    void main()
    {
        auto cc = new CoolClass!true();
        if (cc.type@isCool) { // true
            // Do something cool...
        }
    }

and of course, the compiler could make use of attribute metadata 
during codegen. Things like Garbage Collection and memory 
compaction attributes come to mind:

    class MemoryPool
    {
        @GC.DontScan void*[] pool;
        @Int.Fast int index; // replace stdint
    }

Also, aliasing could be possible:

   @Int.Fast alias int intf;
   @Int.Least alias int intl;
March 18, 2012
Re: Proposal: user defined attributes
F i L wrote:
>     class CoolClass(bool cool)
>     {
>         @CoolType(cool);
>         int type;
>     }

typo **@Cool(cool);

plus, I think a better syntax for attributes might be to have an 
attribute keyword for definitions and only use "@" for 
application:

attribute struct CoolType { ... }
attribute bool isCool;

@CoolType @(isCool = true) string coolText;
March 18, 2012
Re: Proposal: user defined attributes
On 3/17/2012 9:12 PM, F i L wrote:
> Walter Bright wrote:
>> I also do not get why per-instance attributes even exist, as I agree that's
>> what fields are for.
>
> Attributes are per-type (type properties, methods, etc), not per-instance, and
> only accessible (in C#) through type reflection (to my knowledge). According to
> http://msdn.microsoft.com/en-us/library/z919e8tw(v=vs.80).aspx attribute objects
> aren't constructed until reflected upon.

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.
March 18, 2012
Re: Proposal: user defined attributes
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? In that 
case, there's two  benefits I can think of over "traditional" 
member data: Instance memory (attributes are create at 
reflection), and reusable metadata packages (similar to how you 
might use mixin templates only with less noise and reflection 
capabilities).
March 18, 2012
Re: Proposal: user defined attributes
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.

> In that case, there's two
> benefits I can think of over "traditional" member data: Instance memory
> (attributes are create at reflection),

Lazy initialization is a standard pattern. No special language features are 
needed for it.

> and reusable metadata packages (similar
> to how you might use mixin templates only with less noise and reflection
> capabilities).

Sounds like a garden variety user-defined data type.

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.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home