These are chat archives for akkadotnet/akka.net

17th
Mar 2015
jcwrequests
@jcwrequests
Mar 17 2015 00:49

@nvivo @Aaronontheweb I have been playing around with a few ideas dealing with calling Context.ActorOf<SomeActor>().Tell(message); from within an actor that was created using the DI Extension but that extension not being used by the extension method.

namespace Akka.Actor
{
     public static class ActorRefFactoryExtensions
     {
         public static ActorRef ActorOf<TActor>(this ActorRefFactory factory, string name = null) where TActor : ActorBase, new()
        {
            return factory.ActorOf(Props.Create<TActor>(), name: name);
        }
     }
 }

Every time I tried to make it transparent it just got messy. It's not to say it can't be done but I think it's not worth the effort. That being said I came up with my own prototype of an extension for the DI.Core that works but requires you to add the namespace which is kind of a compromise because @nvivo you were looking for something not requiring you to know that you are using the DI extension but I think it works. What do you think?

   public static ActorRef ActorOf<TActor>(this IActorContext context, string name = null) where TActor : ActorBase, new()
    {

        var producer = context.System.GetExtension<DIExt>();
        return context.ActorOf(producer.Props(typeof(TActor).Name),name);

    }

You still have to be careful but it turns this

   var producer = Context.System.GetExtension<DIExt>();
   Context.ActorOf(producer.Props("TypedWorker")).Tell(message);

Into this

  Context.ActorOf<TypedWorker>().Tell(message);
jcwrequests
@jcwrequests
Mar 17 2015 01:03
Also I think it may be a good idea to be explicit in this scenario to something like Context.DI().ActorOf<TypedWorker>() Either way if everyone thinks its a good idea I will put in a PR.
Aaron Stannard
@Aaronontheweb
Mar 17 2015 03:18
@jcwrequests I think adding some extension methods off of the IActorContext is a good idea
IMHO, I wouldn't worry about trying to make it 100% transparent - I'd actually argue that that's a bad thing
making it convenient is a worthy goal
but hiding the fact that DI is involved might actually be a bad idea - TL;DR; your props are the contract for how actors get created and since you can't serialize DI kernels and remote deploy them, making it really obvious that this is an actor that depends on DI and therefore can't be remote deployed is a good thing
Aaron Stannard
@Aaronontheweb
Mar 17 2015 03:23
IIRC JVM Akka hasn't tried to do this, but at some point in the future we might be able to signal via configuration that a remote-deployed actor needs to be created via a specific IndirectActorProducer, which means we could remotely deploy actors that use DI (assumes that both ends of the connection have the correct DI bindings needed to do it)
so your idea to make the call explicit like this Context.DI().ActorOf<TypedWorker>() == :+1:
Roger Johansson
@rogeralsing
Mar 17 2015 05:27
Agree with the context.di().actorof :+1:
Bartosz Sypytkowski
@Horusiath
Mar 17 2015 08:39
I've proposed that actor's with stash support should implement stashing in lazy manner - stash would be initialized only when Stash method is actually called. What is your opinion @/all ?
Roger Johansson
@rogeralsing
Mar 17 2015 08:53
I'm all for that.. the more lazy we can be on actor stuff, the better
Roman Golenok
@shersh
Mar 17 2015 10:13
Hi guys. Is akka.net is good for turn-based game ? Any examples exists?
Bartosz Sypytkowski
@Horusiath
Mar 17 2015 10:27
AFAIK there are no open sourced examples, but turn-based games shouldn't be a problem
Roman Golenok
@shersh
Mar 17 2015 12:38
What is best practices for Client side programming with akka back-end? I saw examples and they all using akka libs inside. For example chat. but what if I want client in mobile? I can't use akka in there
Roger Johansson
@rogeralsing
Mar 17 2015 12:40
then you would expose e.g. a web api service that talks rest with the client, and talks to akka on the inside
or pipe messages from akka to signalR and back
Emilian Ionascu
@emilianionascu
Mar 17 2015 12:52
hey guys
I like the idea of actors - been following it ever since it started in the Scala world a couple of years ago
I would like to extend a big thanks to the team that ported it to the .NET world
however I am sometimes wondering if the implementation could be a bit more idiomatic with regards to C# best practices and recommendations
as an example, I see quite often that static classes are being used, extensive use of the extension methods, nested classes definitions and others
Emilian Ionascu
@emilianionascu
Mar 17 2015 12:58
those are code smells that in the future might make using and testing the library cumbersome
Bartosz Sypytkowski
@Horusiath
Mar 17 2015 13:22
@emilianionascu could you provide more details? It's always good to match different opinions, but to be constructive one, it must be concrete first.
Roger Johansson
@rogeralsing
Mar 17 2015 13:54
there are a lot of code in each file, but that is a herritage from the scala code as we have tried (for better or worse) to align the code that way so we can compare files from the original scala and our port.
Bartosz Sypytkowski
@Horusiath
Mar 17 2015 14:15
@rogeralsing I actually like this approach, where your code files are divided by responsibility rather than type definitions. C# is not Java clone anymore.
Natan Vivo
@nvivo
Mar 17 2015 14:54
What's the problem with static classes, nested classes and extension methods? I don't see why those specific examples would be considered bad practices or against recommendations in any way.
@jcwrequests good idea. Too bad C# doesn't have extension properties.
Aaron Stannard
@Aaronontheweb
Mar 17 2015 16:56
and I agree with @nvivo - ain't nothing wrong with any of those
Bartosz Sypytkowski
@Horusiath
Mar 17 2015 17:37
thx @Aaronontheweb
Roger Johansson
@rogeralsing
Mar 17 2015 18:50
unrelated, but playing around with a thread pool impl with @Aaronontheweb for akka.net, anyone know the answer to this? http://stackoverflow.com/questions/29107314/lockfree-read-value-after-interlocked-exchange
Bartosz Sypytkowski
@Horusiath
Mar 17 2015 18:55
I see, you @rogeralsing have a long talk on Twitter with Orleans people :)
Roger Johansson
@rogeralsing
Mar 17 2015 19:37
Art of war ;) j/k just wanted to understand how it works
Max Gortman
@nayato
Mar 17 2015 19:48
@rogeralsing really, how come volatile does not help?
Bartosz Sypytkowski
@Horusiath
Mar 17 2015 19:48
I've just seen Riccardo presentation, it's really nice :)
Max Gortman
@nayato
Mar 17 2015 19:51
ridiculous option: Interlocked.CompareExchange(ref bar, null, null) which returns old value and as both comparand and new value are null, it would not mess things up. but volatile should really be enough..
Roger Johansson
@rogeralsing
Mar 17 2015 20:58
Ty :) Ill try that out. Could be some brain fart on my side
Stefan Sedich
@stefansedich
Mar 17 2015 22:28
man I hate not being in here for a couple days, so much to read back on!