digitalmars.D.bugs - [Issue 10023] New: Add rtInfo (or equivalent) to ModuleInfo
- d-bugmail puremagic.com (21/21) May 03 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10023
- d-bugmail puremagic.com (11/11) Jun 15 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10023
- d-bugmail puremagic.com (12/12) Jun 28 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10023
- d-bugmail puremagic.com (14/14) Jun 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10023
- d-bugmail puremagic.com (28/28) Jun 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10023
http://d.puremagic.com/issues/show_bug.cgi?id=10023 Summary: Add rtInfo (or equivalent) to ModuleInfo Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: schveiguy yahoo.com 14:42:52 PDT --- Currently, we have rtInfo for TypeInfo instances, which is a compile time-generated member based on the library template RTInfo. It would be nice to have this same mechanism for ModuleInfo instances. This would be very helpful for many different nifty runtime features, such as precise garbage collection, or fixing cyclic import dependencies. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 03 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10023 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs eml.cc I think this is a significant feature, so I think it's better to explain better its advantages and usages (like for a unittest system). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 15 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10023 Jacob Carlborg <doob me.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |doob me.com Pull requests: https://github.com/D-Programming-Language/dmd/pull/2271 https://github.com/D-Programming-Language/druntime/pull/534 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 28 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10023 I have an idea how to make RTInfo and my proposed RMInfo, in the pull request, work outside object.di. 1. We add a new struct (rtIfno/rmInfo) to object.di as an UDA recognized by the compiler 2. If a template that have the correct signature and the object.rtInfo UDA attached, instantiated that as RTInfo/RMInfo 3. Collect the result of the RTInfo/RMInfo template in an associative array. The keys will be the fully qualified name of the module the template is defined in, the values will be what the same as now -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 29 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10023 I had an idea how to use this for unit tests. We add a new traits that will return all the unit test functions of the given module. RMInfo can then be used to collect all these unit tests functions at compile time. The advantage of doing it at compile time is because then it's possible to access UDA's attached to the unit tests. This would basically make it possible to implement named unit tests in library code: // UDA struct name { string name; } name("foo") unittest { assert(1 +2 == 3); } This is also more flexible then named unit tests implemented in the language. One could use UDA's to do a more RSpec version of unit tests: struct describe { string desc; } struct it { string desc; } desctibe("Address.validate") { it("should validate the address") { assert(true); } } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 29 2013