Comments

Just stick to the tech. Nobody cares about other opinions.

Had a even better idea. The actor framework exposes Read() and Write() methods to every actor.  The actor maintains a RW lock internally via a r/w scheduler.  All properties must be accessed via Read or Write methods and not directly.  The framework will pass either a read actor reference or a Write reference to the lambda as needed.  A read reference can't be cast to a write interface, etc.  With a Read reference object, you can only call Read safe methods and properties.

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.

I think Erik talked about remoteable linq and lambda before, but not heard anything.

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.

Good one. Erik, MrCrash is crazy, your the best.

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.

@PriMinister. Huh? The point of SS is "highest" quality possible on your connection and client - not lowest. SS is best.  Your player is in control of the stream. Way it should have been done from beginning. But have it now.   Sure there may be some edges to polish as users hit them.

Think what is really cool is ability to declare your data and invariants as data at the top level, and enforce those invariants globally.  This would make debug and verification easier as you can break any time an invariant meets a rule, and not have to do it all over the place.  Then you can easily jump to the offending code/thread.  Also easier to declare your rules once and let runtime and compiler enforce the rules.

Would also seem like an interesting new place to hookup "events"/hooks for data changes.  The join could notify any subscribers (e.g. IObservers).  

Not sure I understand what happens when child wins and parent losses in general.  Does the parent restart?  Could you explain with some kind of UI and backing store example?  TIA !

I got one better idea.  Use the action of the downward keystroke with mini-generators that store power in a common battery. Settable resistence would allow more tactile feel and generate more power.  Imagine how much power we generate with everyone having one. Almost more then the Matrix.

You guys don't have to wait for this to get started.  Goto tinyclr.com now and buy a $35 panda or mini.  The gadgetter connectors will make hooking things up easier, but there still is a lot of goodness to be learned on the MF today.  tinyclr sells a bunch of plug and play sensors and things already, so it is real easy (i.e. freakin ez) and you don't have to wait.  They also have a great support site and community which helps as the MF docs are slim to none.  I got 3 boards already and control a robot with .Net MF.  Easier then NXT and hooking up tons of blocks imho (but I knew c# already).  Now if I could just a c9 guy as a driver I could make a video

Will the new arc mouse and an arc keyboard leverage the same dongle or need two dongles?

BTW - first mouse that looks like a real evolution in some time.

Yeah.  How I wanted this back when doing access apps   Is there  a reporting story yet?