Comments (10)
@ReubenBond - Do you mean to add GrainFactory.CreateObjectReference()?
from orleans.
I was thinking of "ObserverFactory" or "ClientFactory" but yes, pretty much.
-----Original Message-----
From: "Sergey Bykov" [email protected]
Sent: 02/02/2015 06:40
To: "dotnet/orleans" [email protected]
Cc: "Reuben Bond" [email protected]
Subject: Re: [orleans] Replace static codegen'd factory classes with genericfactories (#59)
@ReubenBond - Do you mean to add GrainFactory.CreateObjectReference()?
—
Reply to this email directly or view it on GitHub.=
from orleans.
My personal preference would be to stick to one static factory class, GrainFactory, for better discoverability.
from orleans.
The proposal is to add
public static Task<TGrainObserverInterface> GrainFactory.CreateObjectReference<TGrainObserverInterface>(TGrainObserverInterFace obj);
As well as the matching DeleteObjectReference
method.
LGTYou?
from orleans.
What should the behavior be when a user calls GrainFactory.CreateObjectReference(observer)
where observer
is a concrete type (i.e, not an interface).
Currently it will crash at runtime when it is unable to find the concrete type's factory.
I think the best approach is to force the user to specify the interface in the type parameters, which equates to changing the signature to:
CreateObjectReference<TGrainObserverInterface>(IGrainObserver obj)
: where TGrainObserverInterface : IGrainObserver
Usage then becomes:
var obj = await GrainFactory.CreateObjectReference<ISimpleGrainObserver>(observer);
I'm performing a runtime check that the argument matches the type parameter:
if (!interfaceType.IsInstanceOfType(obj))
{
throw new ArgumentException(
string.Format("The provided object must implement '{0}'.", interfaceType.FullName),
"obj");
}
What do you think?
from orleans.
Do you really need to perform the check at runtime? The compiler won't
allow passing of the object that violates generic parameter restrictions...
On Sun, 1 Feb 2015 22:41 Reuben Bond [email protected] wrote:
What should the behavior be when a user calls
GrainFactory.CreateObjectReference(observer) where observer is a concrete
type (i.e, not an interface).Currently it will crash at runtime when it is unable to find the concrete
type's factory.I think the best approach is to force the user to specify the interface in
the type parameters, which equates to changing the signature to:CreateObjectReference(IGrainObserver obj)
: where TGrainObserverInterface : IGrainObserverUsage then becomes:
var obj = await GrainFactory.CreateObjectReference(observer);
I'm performing a runtime check that the argument matches the type
parameter:if (!obj.GetType().IsAssignableFrom(interfaceType))
{
throw new ArgumentException(
string.Format("The provided object must implement '{0}'.", interfaceType.FullName),
"obj");
}What do you think?
—
Reply to this email directly or view it on GitHub
#59 (comment).
from orleans.
I can't have generic parameter restrictions to say T
is an interface
, though. The compiler will infer the most specific type possible, which will be the concrete type.
To make it less error prone, I changed the type in the parameter list to IGrainObserver
rather than TGrainObserverInterface
- that forces the consumer to specify the interface type (which I can only check at runtime).
Maybe I'm missing something, though. Do you have a suggestion for how I can improve this?
from orleans.
Just an idea, would IsAssignableFrom
be an option here?
- http://www.hanselman.com/blog/DoesATypeImplementAnInterface.aspx
- http://stackoverflow.com/questions/12160460/when-is-obj-gettype-isinstanceoftypetypeofmyclass-true
from orleans.
The compile will already enforce
where TGrainObserverInterface : IGrainObserver
At run time, don't we just need to check that it's an interface via
obj.GetType().IsInterface
?
from orleans.
We do a couple of sanity checks:
- Is
TGrainObserverInterface
an interface: the compiler enforces that it implementsIGrainObserver
as you said, @sergeybykov. - Is
obj
an instance ofTGrainObserverInterface
: the compiler only check that it implementsIGrainObserver
, but not its relationship toTGrainObserverInterface
.
The type system cannot infer the interface from the concrete type, so the user must explicitly provide it. We cannot specify a relationship between obj
and TGrainObserverInterface
while forcing the user to specify TGrainObserverInterface
unless we also force them to explicitly specify the type of obj
.
i.e:
// Bad: TInterface is concrete type
Task<TInterface> CreateObjectReference<TInterface>(TInterface obj) where TInterface : IGrainObserver
// Correct, but the user has to specify both types explicitly
Task<TInterface> CreateObjectReference<TInterface,TConcrete>(TConcrete obj) where TInterface : IGrainObserver where TConcrete : TInterface
// Only runtime checks can verify relationship between `obj` and TInterface
Task<TInterface> CreateObjectReference<TInterface>(IGrainObserver obj) where TInterface : IGrainObserver
from orleans.
Related Issues (20)
- Question: custom persistence of IGrainObserver HOT 5
- Could not find an implementation for interface error when using grain persistence HOT 14
- Unable to activate Grains in Orleans Runtime HOT 1
- 8.0-rc1 - AddServiceByName is gone. HOT 9
- Deleting state of transactional grain
- Orleans crashes on Azure Web App when Application Insights is enabled HOT 4
- Keeping long lived client hosted stream subscriptions alive HOT 1
- Duplicate key item with isolated interface when it is shared in more than one isolated assembly
- Is there any recommended way how can we configure projection handlers to generate the read models for the event sourced grains? HOT 4
- Simple DI for unit tests? HOT 2
- Effects of using a single stream id + namespace for an event hub stream
- [API Proposal]:
- [API Proposal]: Allow implementing ICustomStorageInterface separately from the Grain HOT 2
- Grain Timer stop firing after a while HOT 4
- Can i get the method name from the InvokeMethodRequest.MethodId
- Custom BroadcastChannel provider? HOT 4
- Mark the AlwaysInterleaveAttribute attribute method can be interleaved with itself? HOT 3
- Orlerans 8 - Dependency on Microsoft.CodeAnalysis >= 4.8.0 HOT 3
- `OnActivateAsync` does not seem to follow the `CancellationToken` pattern
- `CancellationTokenSource` used for `OnActivateAsync` timeout is not disposed
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from orleans.