Re: Aedi - a dependency injection library
On Thu, Aug 18, 2016 at 8:56 PM, Alexandru Ermicioi via Digitalmars-d-announcewrote: > On Tuesday, 16 August 2016 at 19:24:22 UTC, Rory McGuire wrote: > >> On 16 Aug 2016 20:45, "Alexandru Ermicioi via Digitalmars-d-announce" < >> digitalmars-d-announce@puremagic.com> wrote: >> >>> >>> On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote: >>> On 2016-08-16 11:41, Alexandru Ermicioi wrote: https://github.com/aermicioi/aedi > If you use: ```d ``` For the code block you'll get syntax highlighting for D. >>> >>> >>> Thx, for info. Didn't know about such syntax. I'll update it with next >>> >> batch of modifications. >> >> Can this be used to do function >> currying? http://stackoverflow.com/questions/36314/what-is-currying >> >> Seems like an interesting feature. I imagine it would use templates or a >> wrapper struct instead of wrapped functions though. >> > > Thank you, for sharing with an idea :) > > I'm not sure if I understand your proposition correctly. > > I assume that you meant the call of register function on container to > register an object in it. If so, by applying currying, we would get > something like: > > container.register!Type()("constructor")("setter", "setterArg"); // And > so on. > > It's an interesting idea, but I'm not sure if it will allow an easy > customization of register api :(. > > Could you please explain it in more detail? > No probs, example: / module m1; /// this module contains standard functions / classes etc... auto func1(Type1 v1, Type2 v2, Type3 v3) { // do awesome stuff with all three instances } class A { Type4 v4; Type5 v5; this(Type4 v4, Type5 v5) { this.v4 =v4; this.v5=v5; } void changeMode(Type2 v2) { v4.asdf(v2); } void opApply(...) { /// do normal stuff with all these manually passed in instances } } module auto_deps_m1; /// this module has the curryied versions of the original functions and classes from m1; /// What I think would be cool, and I thinks its possible, would be to automatically inject default instance parameters into classes (the Object), and functions. /// so func1 could for example be exposed in this module as: auto func1(Type2 v2) { /// yeah, don't worry about passing the other stuff in, it was all setup during dependency registration } class A { Type4 v4; /// inject this Type5 v5; this(Type5 v5) { this.v5 = v5; // we never registered a Type5 during dependency registration this.v4.changeMode(registered_v2); /// this got moved here due to compile time dependency registration } void opApply(...) { // do stuff, and all we had to supply in other modules that depend on this one is the instance for v5 } } // The function example is what I was thinking initially, but I don't see why it couldn't be done with structs and classes as well. I guess in m2 the code the programmer writes would be similar to: mixin(registrationService.ct_register!(func1)); etc.. If its not possible right now I'd imagine its fairly close to possible. disclaimer: I'm not very familiar with dependency injection in anything but Javascript with AngularJS.
Re: Aedi - a dependency injection library
On Tuesday, 16 August 2016 at 19:24:22 UTC, Rory McGuire wrote: On 16 Aug 2016 20:45, "Alexandru Ermicioi via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote: On 2016-08-16 11:41, Alexandru Ermicioi wrote: https://github.com/aermicioi/aedi If you use: ```d ``` For the code block you'll get syntax highlighting for D. Thx, for info. Didn't know about such syntax. I'll update it with next batch of modifications. Can this be used to do function currying? http://stackoverflow.com/questions/36314/what-is-currying Seems like an interesting feature. I imagine it would use templates or a wrapper struct instead of wrapped functions though. Thank you, for sharing with an idea :) I'm not sure if I understand your proposition correctly. I assume that you meant the call of register function on container to register an object in it. If so, by applying currying, we would get something like: container.register!Type()("constructor")("setter", "setterArg"); // And so on. It's an interesting idea, but I'm not sure if it will allow an easy customization of register api :(. Could you please explain it in more detail?
Re: DIP1000: Scoped Pointers
On 08/11/2016 04:38 PM, Sönke Ludwig wrote: > That will just leave one hole in conjunction with the @trusted > destructor, which is (presumably) not easy to fix without much larger > changes to the type system, as well as to how container types are built. > It is still vulnerable to artificial shortening of the elements' > lifetime, e.g. by using opAssign() or destroy(): > > @safe { > RefCountedSlice!int s = ...; > scope int* el; > el = [0]; > s = RefCountedSlice.init; > *el = 12; // oops > } I asked Walter about this in more details and right now plan is to address it in a separate DIP that provides more integration between reference counting and compiler. Within DIP1000 terms such destructor must not be marked as @safe - essentially, it will only enable @safe usage of stack allocated data in its initial form. > A similar issue affects the library implementation of isolated memory > that I did a while ago: > > @safe { > class C { int* x; } > > // c is guaranteed to be only reachable through this variable > Isolated!C c = makeIsolated!C(); > > // c.x is a @property that returns a specially wrapped reference to > // the actual C.x field - with this DIP this is similar to a 'scope' > // return, but acts transitively > Scoped!(int*) x = c.x; > > // one of the benefits of Isolated!T is that it allows @safe > // conversion to immutable: > immutable(C) ci = c.freeze(); > // c gets cleared by freeze() to disallow any further modifications > > // but, oops, x is still there and can be used to modify the now > // immutable contents of ci.x > *x = 12; > } > > Disallowing the assignment of scope return references to local scope > references (either by default, or using some form of additional > inference/annotation) would solve this particular issue, but not the > issue in general (the assignment/destruction could for example happen in > a nested function call). Note that using scope return in its most basic form will exactly prevent the assigning of reference to a variable because it limits lifetime to expression. signature.asc Description: OpenPGP digital signature
Re: Berlin D Meetup August 2016
Man I wish I was in Berlin. Will be awesome if we get to see a video of this. R On Thu, Aug 18, 2016 at 11:09 AM, Ben Palmer via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > Hi All, > > The August Berlin D Meetup will be happening at 20:00 on Friday the 26th > of August at Berlin Co-Op (http://co-up.de/) on the fifth floor. Note > that this is the fourth Friday of the month rather than the standard third > Friday. > > Stefan Koch is going to tell his war-stories about implementing CTFE. > Expect juicy bits of dmd code and a few rants as well as a birds-eye-view > of how the new engine is going to work. > > There likely won't be slides but instead a few live demos of what the new > engine will be capable of. > > Sociomantic have come to the party once more and will be sponsoring food > (including vegetarian options) and drinks (both alcoholic and > non-alcoholic). > > More details are available on the meetup page here: > http://www.meetup.com/Berlin-D-Programmers/events/233371803/ > > Thanks, > Ben. >
Berlin D Meetup August 2016
Hi All, The August Berlin D Meetup will be happening at 20:00 on Friday the 26th of August at Berlin Co-Op (http://co-up.de/) on the fifth floor. Note that this is the fourth Friday of the month rather than the standard third Friday. Stefan Koch is going to tell his war-stories about implementing CTFE. Expect juicy bits of dmd code and a few rants as well as a birds-eye-view of how the new engine is going to work. There likely won't be slides but instead a few live demos of what the new engine will be capable of. Sociomantic have come to the party once more and will be sponsoring food (including vegetarian options) and drinks (both alcoholic and non-alcoholic). More details are available on the meetup page here: http://www.meetup.com/Berlin-D-Programmers/events/233371803/ Thanks, Ben.