Le 22/03/2012 03:05, Andrei Alexandrescu a écrit :
> On 3/21/12 6:02 PM, deadalnix wrote:
>> Le 21/03/2012 17:22, Andrei Alexandrescu a écrit :
>>> On 3/21/12 11:17 AM, Timon Gehr wrote:
>>>> On 03/20/2012 10:36 PM, deadalnix wrote:
>>>>> Even the propagation of pure, @safe, nothrow and const that has been
>>>>> discussed recently can be done with that feature.
>>>>>
>>>>
>>>> I'm sceptical. How would that work exactly?
>>>
>>> I, too, am highly skeptical. For one thing these attributes must be made
>>> part of the type and have deep connections with code semantics.
>>>
>>> Andrei
>>
>> That is the point. The property must be able to manipulate what is
>> qualified. This is the point of AOP.
>
> Problem is you'd need a ton of hooks to e.g. prevent mutation in const
> methods, or do attribute inference as the compiler does now.
>
>> If you let me some time, I could write a proposal. BTW, this is probably
>> something we don't want to rush in, but I'm sure it definitively worth
>> it.
>
> Honest, I have zero enthusiasm for adding AOP to D right now. But I
> agree it would be an interesting project to see what it would take to
> implement something of the power of pure or const starting from zero
> knowledge.
>

I think we have a misunderstanding here. I wasn't talking about reimplementing const or pure. I was talking about propagating them to overriden method (a way more easier task). I was talking about implementing the recently discussed behavior of override, not actually reimplementing const or pure. Not that that wouldn't be possible, but it would require a massive amount of work and a very cooperative compiler.

Inference isn't possible with an attribute system.

This is less impressive, but more realistic goal. And that is quite easy to achieve.

>> Have you seen what a project like lombok can do ?
>
> This? http://projectlombok.org/ I'll take a look, thanks.
>

Yes.

On Thursday, 22 March 2012 at 23:48:03 UTC, deadalnix wrote:

> Inference isn't possible with an attribute system.

It isn't possible simply because it wasn't implemented yet. nothing prevents us to add such a feature in the future. Could be a worthwhile enhancement for D3 or D4, given we actually have attributes implemented before then.

On 2012-03-22 02:23, Tove wrote:

> mixin(attr(q{struct Foo
> {
> @NonSerialized int x;
> @NonSerialized int y;
> int z;
> }}));
>
> void main()
> {
> auto m = [ __traits(allMembers, Foo) ];
> writeln("Normal members of Foo:", m);
>
> auto n = [ __traits(allMembers, Foo_Serializable) ];
> writeln("Serializable members of Foo:", n);
> }
>

Just really ugly and it creates a new type, completely unnecessary if D supported user defined attributes.

-- 
/Jacob Carlborg

On 2012-03-22 08:17, Manu wrote:

> By this logic, I might as well stick with C++. It's 'possible' to do
> everything I need, but it makes my cry myself to sleep at night, and
> wastes insane amounts of time.
> Code simplicity and cleanliess on the front end IS important, it makes
> code reasable, maintainable.
> In a large code team, if someone has to go out of their way to
> understand some code, chances are, they won't understand it, and make
> improper or damaging changes to it. Or make improper implementations
> based on it.
> This will destroy your code across 5 years or so. In gamedev, the
> average engine codebase lasts 10+ years.

Yes, I completely agree.

-- 
/Jacob Carlborg

On 2012-03-22 15:31, Artur Skawina wrote:

> For run-time accessible custom attributes (if those are even necessary),
> the lib solution wouldn't be much different than a built-in one anyway.
>
> artur

Accessing the custom attributes at runtime are necessary. Serialization is one example that could take advantage of that.

-- 
/Jacob Carlborg

On Sunday, 25 March 2012 at 15:24:18 UTC, Jacob Carlborg wrote:
> On 2012-03-22 02:23, Tove wrote:
>
>> mixin(attr(q{struct Foo
>> {
>> @NonSerialized int x;
>> @NonSerialized int y;
>> int z;
>> }}));
>>
>> void main()
>> {
>> auto m = [ __traits(allMembers, Foo) ];
>> writeln("Normal members of Foo:", m);
>>
>> auto n = [ __traits(allMembers, Foo_Serializable) ];
>> writeln("Serializable members of Foo:", n);
>> }
>>
>
> Just really ugly and it creates a new type, completely unnecessary if D supported user defined attributes.

Well... "eye of the beholder"... I think that's exactly the beautiful part, because:
1) The original type is 100% unaltered...
2) Easy for the compiler to optimize the new type away as it's never instantiated, nor used beyond ctfe reflection i.e. 0 runtime overhead.
3) It trivially allows using the built-in traits system everyone already is familiar with.

but I wonder if one can do better with a mixin template, accessing it's "parent"...

>>> Note that one library that did attempt runtime reflection capability
>>> (flectioned) does all this at runtime, and does some really funky shit,
>>> like opening /proc/self/map on Linux, or requiring you to pass an
>>> OPTLINK map file. I don't look at these as "innovations" as much as I do
>>> as workarounds.
>>
>> Maybe there's a better approach than flectioned. Consider the language is frozen solid. How would you solve problems with it?
>
> I think the closest anyone has come is Jacob, with his orange library.  Maybe he can respond to this point.
>
> -Steve

Just showing this because it never comes up that one can already implement
runtime reflection using ModuleInfo.xgetMembers and TypeInfo_Struct.xgetMembers.

module a;
import std.stdio, std.variant;

void main()
{
    foreach(m; ModuleInfo)
    {
        if (m.name != "b") continue;
	// getMembers currently doesn't work for classes,
        // but it does for modules/structs
        auto get = cast(Variant function(string))m.xgetMembers;
        auto bfunc = get("bfunc").get!(size_t function());
        writeln(bfunc());
    }
}


module b;
import std.variant;

// a pointer to this method will end up in ModuleInfo xgetMembers
Variant getMembers(string name)
{
    Variant res;
    switch (name)
    {
    case "bfunc": return Variant(&bfunc);
    default: return Variant("member "~name~" not found");
    }
}

size_t bfunc()
{
    return 2;
}

It should be fairly easy to construct some helpers that make the compile time data digestible.

On 2012-03-28 03:41, Martin Nowak wrote:

> Just showing this because it never comes up that one can already implement
> runtime reflection using ModuleInfo.xgetMembers and
> TypeInfo_Struct.xgetMembers.
>
> module a;
> import std.stdio, std.variant;
>
> void main()
> {
> foreach(m; ModuleInfo)
> {
> if (m.name != "b") continue;
> // getMembers currently doesn't work for classes,
> // but it does for modules/structs
> auto get = cast(Variant function(string))m.xgetMembers;
> auto bfunc = get("bfunc").get!(size_t function());
> writeln(bfunc());
> }
> }
>
>
> module b;
> import std.variant;
>
> // a pointer to this method will end up in ModuleInfo xgetMembers
> Variant getMembers(string name)
> {
> Variant res;
> switch (name)
> {
> case "bfunc": return Variant(&bfunc);
> default: return Variant("member "~name~" not found");
> }
> }
>
> size_t bfunc()
> {
> return 2;
> }
>
> It should be fairly easy to construct some helpers that make the compile
> time data digestible.

I had no idea that xgetMembers work at all. But as the comment says, it doesn't work for classes.

-- 
/Jacob Carlborg