Decide on structure of solution and API surface about protoactor-dotnet HOT 4 CLOSED

Some initial thoughts:
It's not important to follow the API of Go in C# in a verbatim way. as long as the concepts are the same, its all fine.
I'm all for being idiomatic, driving adoption would be hard if the API feels alien.
My vote goes to ".NET and Go have different conventions and capabilities"

The only really important aspect is that the proto contracts and the named base actors are present in both C# and Go.

Should the structure of the NuGet packages map 1-to-1 to the structure of the Go packages?

As you point out, importing stuff in Go is easier.
IMO, it would make little sense in having mailboxes as a separate library in .NET.
(I'm undecided on Routing, it might OK or it might be too fine grained to have that in a separate lib)

Go lacks namespaces - in C# code they are often abundant. Should we keep the flat structure of the Go API or should certain things be moved into sub-namespaces?

Let's go for what is most idiomatic. in .NET you can have circular deps between namespaces, in Go you can only have your flat package and sub packages.
Not sure how that should look or what goes where on the top of my head.

In Go, non-receiver functions are accessed through ., e.g. actor.Spawn(). The

IMO, Actor.FromProducer and Actor.Spawn reads sort of nice. but that shouldnt really be an argument for having code with conflicts.
We could do what the TPL does, use Actors as the namespace and Actor as the Static API.
maybe even make Proto the root namespace so we have

• Proto
• Proto.Actor (API)
• Proto.Actors (related types, Props and what not)
• Proto.Mailbox (API)
• Proto.Mailboxes (impls)

Not sure if that is a good idea, just throwing stuff out there :-)

In Go, there is only one way to access a field on the underlying struct of an interface - through receiver

As this code has real side-effects like spinning up a timer, I would like to avoid a property setter for it.
Having a SetReceiveTimeout(..) makes readers see that this might be more than just mutating a value.
But we could absolutely have a ReceiveTimeout get prop to read and reason about the timeout.

Not sure I actually answered anything :-P but lets brainstorm a bit and try to come up with something that will work long term for the API

from protoactor-dotnet.

I'm all for being idiomatic, driving adoption would be hard if the API feels alien. My vote goes to ".NET and Go have different conventions and capabilities"

I too am going to vote in favor of this approach. Regardless of the community, whether it be .NET or Go, adoption is definitely driven up by familiar patterns and following idioms. If the core concepts and tenants are familiar between implementations, we'll be in great shape.

Great discussion!

from protoactor-dotnet.

Cool, we all agree on idiomaticity over consistency then :)

as long as the concepts are the same, its all fine

Perhaps it would be good to clearly define what the concepts are - somewhat like a glossary? Would be useful both for documentation and for keeping an eye on whether the APIs diverge in a way they shouldn't. Random idea: it would be great to have language-agnostic documentation based around these core concepts, with examples in both languages. Thoughts?

IMO, it would make little sense in having mailboxes as a separate library in .NET.

Not necessarily - there could be use-cases where you want just an asynchronous mailbox without a full actor system. E.g. the Zipkin tracing stuff we've been working on where we do use a mailbox to collect spans :)

Actor.FromProducer and Actor.Spawn reads sort of nice. but that shouldnt really be an argument for having code with conflicts.
We could do what the TPL does, use Actors as the namespace and Actor as the Static API.
maybe even make Proto the root namespace so we have

They would still read like that from user-code though - it's only internally that you'd get namespace conflicts (because if you're in the namespace Proto.X, the compiler will interpret Actor as the namespace Proto.Actor, even if you add a using statement for Proto.Actor).

But would we then use Proto as the namespace for the whole public API? I.e. all packages have the same namespace. It could be nice for the user since you'd get less namespace bloat - but it could also make auto-completion worse if you get too many types available from one namespace. Anyway, something we could consider - it's not unheard of either, MS re-uses namespaces in multiple assemblies all the time.

As this code has real side-effects like spinning up a timer, I would like to avoid a property setter for it.

Yeah a property getter with a set method feels like the way to do it. Having logic in property setters is kind of frowned upon these days :) As you say, a property indicates no side-effects, whereas a method indicates there are.

from protoactor-dotnet.

This feels like it's pretty much done and settled.

from protoactor-dotnet.