1) Strings. Calling by method name (i.e. string) has the high road in terms of loose coupling. To gain the local typing, could always wrap in a typed client proxy class (or the tool could build them like service references). Not sure how enums would be used in terms of calling methods. But auto generated typed proxies from meta-data on the uri seems to work fine in other remoting frameworks. And the lower layer stays loose. I suppose a win-win. I am curious if a meta-data public interface method will be added to return method/property names and return types.

2) Reflection. I am not clear where you feel reflection would be required in a method body. Maybe a use case example would help.

3) Message passing.  Sync or Async, it is message passing either way.  You can layer async on any sync method or visa-versa.  AFAICT their Pub/sub is orthogonal to the subject of sync or async method invocation (i.e. message passing).

4) State Machines. I see nothing stopping one from implementing state machine in the actor and methods do actions based on current state. If, on the other hand,  IAsyncState consistency is the concern, then that appears to be handled by correct construction of running delegates syncronously on a single thread. I may have missed your intention.

posted by staceyw

posted by staceyw

1) Namespace is "$safeprojectname$", which fails to compile. Is this a left over from internal build system?

2) Project references System.Fabric, which is broken link. Where does System.Fabric exist?  I did install the msi already.

TIA

posted by staceyw

This would completely stop the issue of language discussions and what is best. As Anders has pointed out in past, language design is hard and is almost never right out of the gate and incorrect assumptions are always made and you can't change it after release which means you have to spend 5-10 years on beta before release for something this big.  It seems forcing javascript on everyone in the browser goes against the whole open INET mentality from the start. 

posted by staceyw

posted by staceyw

posted by staceyw

Shards and multi-tenant is really welcome feature.

posted by staceyw

posted by staceyw

posted by staceyw

posted by staceyw

posted by staceyw

But calling TextChanged is up to publisher. So publisher would not call if not changed. Changing that behavior was not part of the challenge as I read it.  Was fun series in any event (pun intended). 

posted by staceyw

posted by staceyw

1) Your LengthChanged event is always fired after textchanged, even if Length does not change. So it fires too much.

2) The challenge had a template to follow and not remove getter/setter (i.e. Add, Remove) on the new event afaict.

posted by staceyw

namespace IntroductionToRx
{
    class Events
    {
        public event Action<string> TextChanged;
        private event Action<int> lenChanged;
        private int lastLen;

        public virtual void OnTextChanged(string text)
        {
            var t = TextChanged;
            if (t != null)
                t(text);
            if (lastLen != text.Length)
            {
                lastLen = text.Length;
                OnLenChanged(text.Length);
            }
        }
        public virtual void OnLenChanged(int len)
        {
            var t = lenChanged;
            if (t != null)
                t(len);
        }
        public event Action<int> LengthChanged
        {
            add
            {
                lenChanged = (Action<int>)Delegate.Combine(lenChanged, value);
            }
            remove
            {
                lenChanged = (Action<int>)Delegate.Remove(lenChanged, value);
            }
        }
    }
}

namespace IntroductionToRx
{
    class Observables
    {
        ISubject<string> textChanged = new Subject<string>();
        int lastLen;

        public virtual void OnTextChanged(string text)
        {
            textChanged.OnNext(text);
        }

        public IObservable<string> TextChanged { get { return textChanged; } }

        public IObservable<int> LengthChanged
        {
            get
            { // Compose new "event" by filtering existing event.
                return textChanged.Where(s => s.Length != lastLen).Do(s=>lastLen=s.Length).Select(s=>s.Length);
            }
        }
    }
}

Output
======================
*** Events ***
The
Reactive
Extensions
10
are
3
13
*** Observables ***
The
Reactive
Extensions
10
are
3
13

posted by staceyw

Good work.  Look forward to trying the new bits.  Thank you.

posted by staceyw

Post(1);
// Not atomic.
DeclinePermanently();

Another producer could (and eventually will) sneak in between the calls. The only way to avoid that is code in another sync structure (i.e. lock), which your trying to avoid. Thoughts?

posted by staceyw

posted by staceyw

BTW- Great news on the Dev Center.

posted by staceyw

@staceyw: Yes indeed if you limit usage by proper API design, in any language it's easy to constrain usage to only safe usage the real trick is allowing both power AND correct usage of the abstraction.

Yes. I am not sure this solution gets us 100% there, but is powerful (allows arbitrary lamba code) and is safe (orders access to state in a sane way). It also would seem to lead down a correct-by- construction path I think. Some details to work out, but think it can work in general and smells nice.

posted by staceyw

posted by staceyw

Task<int> t = actor.Read((readRef)=>
{
     return readRef.X + readRef.Y;
     // Writes not allowed:
     // readRef.UpdateSome(true, 5); // Not even exposed.
});

Task<int> t = actor.Write((writeRef)=>
{
    // I have a write lock inside this lamda to the Actor.
    int i = writeRef.X;
    i = i + writeRef.Y;
    return writeRef.UpdateZ(i); // Write methods exposed.
});

So class may look like:

public class MyActor : Actor
{
    //public Task Read(Func<ActorReader, Task>); // from base.
    //public Task Write(Func<ActorWriter, Task>);
    public int X {get{return x;} set{x = value;}} // Properties only accessable via Read/Write functions above.
    
    [WriterMethod]
    public int UpdateCount(int i);

    [ReaderMethod]
    public int GetCount();
    
    //...
}

So in this way, multiple readers can run concurrently and writers are scheduled between read groups.  My lambda code never has to deal with any lock logic.  The framework can do runtime check and throw if trying to Write inside a Reader lamda. Maybe could even do compile time check.  You adorn Methods with "Write" attributes if the method updates internal state.  Otherwise, the method is assumed to be read only and must not modify internal invariants.  So I think this would solve Erik's issue with Races on properties.  I guess you could take it a step farther and say public methods are only Helpers and just codify some operation you could do yourself with a Read()/Write() lamda.  Maybe even say all methods must use properties and not be able to change private vars. That way, you have only 1 write channel and leverage that.

It also means you have 1 spot to handle rollback if runtime made Write() transactional. If a lamda throws, the runtime just does a rollback to the Entry state before the call.  That means nested graphs would just work also in a call graph. Exceptions just perk to the top and are exposed in your Task<T> future.

posted by staceyw

Got me thinking, that could possibly solve the getter/setter property thing.  Getter/setters could only be accessed via a func call so they would be safe on the single threaded Actor.  It would also be a way sync multiple steps (actor method calls, property updates, actor blocking operation, etc) in single atom operation.  You can not predict or write every possible api someone would need, so you need something like that anyway.  A generic kind of Rest/ADO Data update/query on Actors objects.  Actually, Astoria is similar to the model we are talking about.

actor.Run(()=>
{
    // Public X only settable via a lambda.
    actor.X = actor.X + 1;
});

// Run() is a some special function avalable on all Actors.

posted by staceyw

I do think there is still more discussion to be had on the x= x + 1 problem Erik mentioned on Actor pattern. Do you solve it via convention, static rules, or some other way? Guess would need to list all the use cases and sticky points and toss spegetti at it.

On the Future object deal. I think Erik mentioned before, that when it is future or async, you Need to see the difference so your not back in RPC world which leads the programmer down a path where everything looked local, but is not.  So I think explict difference can be good here. However, I see where that abstraction could be good also.  Maybe there is still a middle ground not seen yet.

posted by staceyw

posted by staceyw