Poodinis (DI framework) 7.0.0 released
Poodinis is a dependency injection framework for the D programming language. It is heavily inspired by the Spring Framework. New in this release is constructor injection. Whenever the dependency container resolves a class it creates an instance of that class. During creation it attempts to resolve dependencies defined in that class' constructor and passes them when created. This is done fully automated without the need of UDAs. Of course member-based injection is still available too. Besides constructor injection, all previously deprecated code has been removed in this version. For more info, see the changelog. You can find the project at: Github: https://github.com/mbierlee/poodinis D package registry: http://code.dlang.org/packages/poodinis
Re: Beta D 2.071.2-b3
On 2016-09-03 18:02, Martin Nowak wrote: Why not just use `__traits(getAttributes, var.tupleof[0])`? I've already updated my code to use the above. When I first implemented it, it was not possible to use a "tupleof expression" as argument to __traits(getAttributes). -- /Jacob Carlborg
Re: Beta D 2.071.2-b3
On Saturday, 3 September 2016 at 14:40:37 UTC, Martin Nowak wrote: Yes, it does help. As private prevents usage outside of a module it allows to do some optimizations that required whole program analysis otherwise, e.g. variables and functions can get internal linkage, thus reducing loads/stores and indirect calls. This doesn't really work that easily due to templates that depend on private data, and private data being referenced from alias parameters. Of course, all such cases can still be statically detected when compiling the module in question, but this is quite a bit less trivial than just looking at the protection level. — David
Re: Beta D 2.071.2-b3
On Wednesday, 31 August 2016 at 06:20:46 UTC, Jacob Carlborg wrote: Class/struct fields are accessible using .tupleof. I was using __traits(getAttributes) in my serialization library to get UDA's for these fields, including private ones. Which is a weird implementation, b/c there is no direct alignment between allMembers and .tupleof. Why not just use `__traits(getAttributes, var.tupleof[0])`? Just serializing private state of types seems flawed too.
Re: Beta D 2.071.2-b3
On Wednesday, 31 August 2016 at 09:56:17 UTC, Johan Engelen wrote: (I can only think of complicated stuff that requires pretty much whole-program analysis to prove validity, and in that case adding `private` doesn't help any more) Yes, it does help. As private prevents usage outside of a module it allows to do some optimizations that required whole program analysis otherwise, e.g. variables and functions can get internal linkage, thus reducing loads/stores and indirect calls.
DIP1001: DoExpression
http://forum.dlang.org/post/nqem7g$1hm6$1...@digitalmars.com signature.asc Description: OpenPGP digital signature
Re: [GSoC] Precise GC
On Friday, 2 September 2016 at 14:55:26 UTC, jmh530 wrote: Anyway, with @safe unions, my thinking is that it would mean that the garbage collector can be made precise in @safe code in a way that it can't in @system code (assuming unions with pointers aren't snuck in through @trusted). GC (and runtime in general) has no idea what code is safe and what code is system. GC works with data at run-time. All @safe-related stuff is about code (not data!) and happens at compile-time. They are completely orthogonal and independent, as I understand.
