Re: Aedi - a dependency injection library

[Rory McGuire via Digitalmars-d-announce]

On Thu, Aug 18, 2016 at 8:56 PM, Alexandru Ermicioi via
Digitalmars-d-announce  wrote:

> 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: DIP1000: Scoped Pointers

[Dicebot via Digitalmars-d-announce]

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

Berlin D Meetup August 2016

[Ben Palmer via Digitalmars-d-announce]

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.

Re: Berlin D Meetup August 2016

[Rory McGuire via Digitalmars-d-announce]

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.
>

Re: Aedi - a dependency injection library

[Alexandru Ermicioi via Digitalmars-d-announce]

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?