-
-
Notifications
You must be signed in to change notification settings - Fork 284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decide on structure of solution and API surface #32
Comments
Some initial thoughts: The only really important aspect is that the proto contracts and the named base actors are present in both C# and Go.
As you point out, importing stuff in Go is easier.
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.
IMO,
Not sure if that is a good idea, just throwing stuff out there :-)
As this code has real side-effects like spinning up a timer, I would like to avoid a property setter for it. 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 |
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! |
Cool, we all agree on idiomaticity over consistency then :)
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?
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 :)
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.
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. |
This feels like it's pretty much done and settled. |
Since we're starting to get the ball rolling on porting all the major features from Go, I think it's time to start discussing how we should structure the solution (files, directories, projects, etc) and also the API surface (packages, naming conventions, namespacing, etc).
To me, the main challenge is that there are two desirable goals that can conflict:
Some concrete questions to get the discussion started:
<package>.<function>
, e.g.actor.Spawn()
. The closest emulation of this in C# is static methods. This can cause internal conflicts with package/namespace names. E.g. if you have a namespaceProto.Actor
containing a static classActor
, it will have to be referenced asActor.Actor
. Shouldn't cause issues for user-code, but might be a bit messy internally.mailbox.NewBoundedProducer()
. Should we keep this pattern/naming convention to make the APIs identical, or should we instead use class constructors, e.g.new BoundedMailboxProducer()
?context.SetReceiveTimeout()
orcontext.ReceiveTimeout()
. In C# this could be implemented with a non-automatic propertycontext.ReceiveTimeout
for both get/set; or with an automatic property with a private setter and a publiccontext.SetReceiveTimeout()
(if you don't want complex logic inside the setter); or with a private field and both acontext.GetReceiveTimeout()
and acontext.SetReceiveTimeout()
method. How should we value idiomaticity vs. consistency?The text was updated successfully, but these errors were encountered: