On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
> Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some frameworks/libraries hold me back, wish I could do everything in D.

I'd wish for attributes to be runtime available, not only compiler directives. It could then be used for a number of interesting use cases, as marshaling from and to different formats rather than through API. The attributes could then be supported by libraries.

On 5 October 2015 at 03:44, Jan Johansson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
>>
>> Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some frameworks/libraries hold me back, wish I could do everything in D.
>
>
> I'd wish for attributes to be runtime available, not only compiler directives. It could then be used for a number of interesting use cases, as marshaling from and to different formats rather than through API. The attributes could then be supported by libraries.

Anything compile time can be made available at runtime if your system calls for it.

On Sunday, 4 October 2015 at 23:55:42 UTC, Manu wrote:
> On 5 October 2015 at 03:44, Jan Johansson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
>>>
>>> Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some frameworks/libraries hold me back, wish I could do everything in D.
>>
>>
>> I'd wish for attributes to be runtime available, not only compiler directives. It could then be used for a number of interesting use cases, as marshaling from and to different formats rather than through API. The attributes could then be supported by libraries.
>
> Anything compile time can be made available at runtime if your system calls for it.

Sure it can, but I want a dynamic behavior, not a static behavior. Attributes are compiler directives. They are not available at runtime according to the specification of D language. Now take the example at: http://ddili.org/ders/d.en/uda.html, and separate the code into one library that defines the attributes and "printAsXML", keep the consumer of the attributes (main function) and get the same slick functionality. It can't be done, because UDA is not runtime available.

On 5 October 2015 at 14:02, Jan Johansson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 4 October 2015 at 23:55:42 UTC, Manu wrote:
>>
>> On 5 October 2015 at 03:44, Jan Johansson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
>>>>
>>>>
>>>> Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some frameworks/libraries hold me back, wish I could do everything in D.
>>>
>>>
>>>
>>> I'd wish for attributes to be runtime available, not only compiler directives. It could then be used for a number of interesting use cases, as marshaling from and to different formats rather than through API. The attributes could then be supported by libraries.
>>
>>
>> Anything compile time can be made available at runtime if your system calls for it.
>
>
> Sure it can, but I want a dynamic behavior, not a static behavior. Attributes are compiler directives. They are not available at runtime according to the specification of D language. Now take the example at: http://ddili.org/ders/d.en/uda.html, and separate the code into one library that defines the attributes and "printAsXML", keep the consumer of the attributes (main function) and get the same slick functionality. It can't be done, because UDA is not runtime available.

You can easily make attributes effectively available at runtime by
building lists of attributed things at compile time.
I don't understand your problem. Describe the goal?

I was one of the main guys involved in the introduction of UDA's, and I have managed to use them successfully for most of my needs.

On Monday, 5 October 2015 at 04:02:58 UTC, Jan Johansson wrote:
> Sure it can, but I want a dynamic behavior, not a static behavior. Attributes are compiler directives. They are not available at runtime according to the specification of D language. Now take the example at: http://ddili.org/ders/d.en/uda.html, and separate the code into one library that defines the attributes and "printAsXML", keep the consumer of the attributes (main function) and get the same slick functionality. It can't be done, because UDA is not runtime available.

printAsXML is templated on the input type and hence can access all its attributes at compile time. If you're familiar with WCF, you should know that all types going through a data contract are known at compile time.

On Monday, 5 October 2015 at 06:18:45 UTC, Manu wrote:
> You can easily make attributes effectively available at runtime by
> building lists of attributed things at compile time.
> I don't understand your problem. Describe the goal?

This is all nice but still not as slick as could be. Say a want to have a central place to lookup all classes with the Foo() attribute on it. The classes can be in several files of course so there are two ways of registering them at compile time to be available for runtime lookups:

1, Add a static module contructor to each module that registers the Foo() attribut'ed classes. This constructor is probably generated at compile time and mixed into the module as a one-liner.

2, Add a "registration" module that imports all other modules in order to filter out Foo() attributed classes and register them for runtime usage.

The first method is bad because you need to mixin code manually for each module you have.

The second method is bad because you need to keep the "registration" file in sync with any modules added/renamed/removed.

A couple of months ago I was working on an extension to the string import() feature of D: It would simply treat a import(*) as returning the directory listing of the imports path. From that the list of .d file could be figured out and imported at compile time. Then the the runtime information could be extracted at compile time with no fuzz.

/Jonas

On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:
> Say a want to have a central place to lookup all classes with the Foo() attribute on it.

You can also use the RTInfo hook in druntime's object.d to build that stuff in a central location.

Of course, since that's a centralized file, it can at best be changed on a per-project basis...

There's also only RTInfo for types, not functions and variables, but still, it'd work for the case of building a list of classes.

On Monday, 5 October 2015 at 08:44:03 UTC, Kagamin wrote:
> On Monday, 5 October 2015 at 04:02:58 UTC, Jan Johansson wrote:
>> Sure it can, but I want a dynamic behavior, not a static behavior. Attributes are compiler directives. They are not available at runtime according to the specification of D language. Now take the example at: http://ddili.org/ders/d.en/uda.html, and separate the code into one library that defines the attributes and "printAsXML", keep the consumer of the attributes (main function) and get the same slick functionality. It can't be done, because UDA is not runtime available.
>
> printAsXML is templated on the input type and hence can access all its attributes at compile time. If you're familiar with WCF, you should know that all types going through a data contract are known at compile time.

Yes, I know WCF more than well, doing my own bindings, federated security bindings, you name it. I also know that WCF works with attribute values during runtime, through reflections and extract aspect oriented instructions on how to treat types. It would be slick to do the same in D.

On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:
> On Monday, 5 October 2015 at 06:18:45 UTC, Manu wrote:
>> [...]
>
> This is all nice but still not as slick as could be. Say a want to have a central place to lookup all classes with the Foo() attribute on it. The classes can be in several files of course so there are two ways of registering them at compile time to be available for runtime lookups:
>
> [...]

Thanks Jonas, for your very good input.

On Monday, 5 October 2015 at 13:38:43 UTC, Adam D. Ruppe wrote:
> On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:
>> Say a want to have a central place to lookup all classes with the Foo() attribute on it.
>
> You can also use the RTInfo hook in druntime's object.d to build that stuff in a central location.
>
> Of course, since that's a centralized file, it can at best be changed on a per-project basis...

And it wouldn't work if you want to put your app on e.g. code.dlang.org for others to compile using their standard druntime. Furthermore RTInfo seems kind of reserved for GC atm.

> There's also only RTInfo for types, not functions and variables, but still, it'd work for the case of building a list of classes.

Types goes a long way for sure. Personally I need both types and functions.