March 22, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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. |
March 23, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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.
|
March 25, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tove | 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 |
March 25, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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 |
March 25, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Artur Skawina | 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 |
March 26, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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"...
|
March 28, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | >>> 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. |
March 28, 2012 Re: Proposal: user defined attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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 |
Copyright © 1999-2021 by the D Language Foundation