C# vNext language design – private protected – FamilyAndAssembly

A better syntax for "private protected" ?

C# vNext will have a new accessibility modifier. The C# team had first proposed to use "private protected", but maybe someone can find a better syntax for it.

On this survey every syntax that’s been proposed so far has been gathered together for everyone to vote on her/his favorite.

WHAT IS THE NEW ACCESSIBILITY MODIFIER ABOUT?This post on StackOverflow has a great explanation.

WHERE CAN YOU JOIN THE DISCUSSION? … Read the motives behind all these proposals – and help shape the future of your favorite programming language – on the CodePlex discussion forum

Go ahead and choose your favorite. The C# team will gathering up answers in mid May.

C# vNext language design – private protected – FamilyAndAssembly

Using The GeoCoordinateReactiveService

Having created an Rx wrapper over the GeoCoordinateWatcher on a previous post, in this post I’ll demonstrate how it can be used in a simple application.


The application will display the status of the service, the position and the distance traveled.


For this simple application the service will be exposed as a singleton property of the App class:


public partial class App : Application
{
    // ...

    public static IGeoCoordinateReactiveService GeoCoordinateService { get; private set; }

    public App()
    {
        // ...

        InitializePhoneApplication();

        // ...
    }

    // ...

    private void InitializePhoneApplication()
    {
        // ...

        GeoCoordinateService = new GeoCoordinateReactiveService();

        // ...

    }

    // ...

}

Getting the status of the service is very simple. It just requires subscribing to the StatusObservable. Since we want to display the status, we need to observe it on the dispatcher before:


App.GeoCoordinateService.StatusObservable
    .ObserveOnDispatcher()
    .Subscribe(this.OnStatusChanged);

For the position we do the same with the PositionObservable:


App.GeoCoordinateService.PositionObservable
    .ObserveOnDispatcher()
    .Subscribe(this.OnPositionChanged);

The distance traveled would seem a bit more complicated because we need to keep track of the last position and calculate the distance traveled on every position change. But this is where the Rx excels with its query operators. If we combine the position observable with the position observable having skipped one position with the zip operator we end up with an observable with the current and previous position. And if we apply a selector, we get the traveled distance:


App.GeoCoordinateService.PositionObservable
    .Zip(
        App.GeoCoordinateService.PositionObservable.Skip(1),
        (p1, p2) => p1.Location.GetDistanceTo(p2.Location))
    .ObserveOnDispatcher()
    .Subscribe(this.OnDistanceChanged);

You can find the complete implementation of the service and application here.




Resources:


Would you like to have roaming settings in Visual Studio?

The C++ Team (blog) has been researching roaming Visual Studio settings and they have a few questions that will help gain insights into what the best experience would be. They have created a survey (http://aka.ms/vsroaming) aimed at understanding Visual Studio settings usage patterns and gathering feedback. The survey should take less than 10 minutes, maybe more if you want to provide a ton of details.


Your voice is important. Make sure it is heard!

A Synchronization Context Based On The TPL Dataflow Library

The purpose of the synchronization model implemented by the SynchronizationContext class is to allow the asynchronous/synchronization operations of the common language runtime to behave properly with different synchronization models. This model also simplifies some of the requirements that managed applications have to follow in order to work correctly under different synchronization environments. Examples of such synchronization environments are user interface infrastructures like Windows Forms, Windows Presentation Foundation and ASP.NET.


Providers of synchronization models extend this class to provide their own implementations. Because these user interface infrastructures usually run on their own threads, dispatching execution to their execution contexts usually means leaving the current thread.


The Task Parallel Library (TPL) provides dataflow components to help increase the robustness of concurrency-enabled applications. These dataflow components are collectively referred to as the TPL Dataflow Library. This dataflow model promotes actor-based programming by providing in-process message passing for coarse-grained dataflow and pipelining tasks. The dataflow components build on the types and scheduling infrastructure of the TPL and integrate with the C#, Visual Basic, and F# language support for asynchronous programming. These dataflow components are useful when you have multiple operations that must communicate with one another asynchronously or when you want to process data as it becomes available.


The TPL Dataflow Library (System.Threading.Tasks.Dataflow namespace) is not distributed with the .NET Framework 4.5. To install the System.Threading.Tasks.Dataflow namespace, open your project in Visual Studio 2012, choose Manage NuGet Packages from the Project menu, and search online for the Microsoft.Tpl.Dataflow package.


Sometimes, for demo or testing purposes, I need a synchronization context that behaves like the user interface ones but doesn’t force me to build applications with a user interface and the TPL Dataflow Library seemed like a good option to implement such synchronization context.


It was as easy as this:


public class TplDataflowSynchronizationContext : SynchronizationContext
{
    private ActionBlock<ActionItem> ab
        = new ActionBlock<ActionItem>(
            item =>
            {
                Trace.WriteLine(
                    string.Format("{0}: {1}", Environment.CurrentManagedThreadId, item.operation));

                try
                {
                    item.d(item.state);
                }
                finally
                {
                    item.SetResult(true);
                }
            });

    public override SynchronizationContext CreateCopy()
    {
        return new TplDataflowSynchronizationContext();
    }

    public override void Post(SendOrPostCallback d, object state)
    {
        Trace.WriteLine(
            string.Format("{0}: Posting...", Environment.CurrentManagedThreadId));

        this.ab.Post(new ActionItem { d = d, state = state, operation = "Post" });

        Trace.WriteLine(
            string.Format("{0}: Posted.", Environment.CurrentManagedThreadId));
    }

    public override void Send(SendOrPostCallback d, object state)
    {
        Trace.WriteLine(
            string.Format("{0}: Sending...", Environment.CurrentManagedThreadId));

        ActionItem item = new ActionItem { d = d, state = state, operation = "Send" };
        this.ab.SendAsync(item);
        item.Task.Wait();

        Trace.WriteLine(
            string.Format("{0}: Sent.", Environment.CurrentManagedThreadId));
    }

    public class ActionItem : TaskCompletionSource<bool>
    {
        public SendOrPostCallback d;
        public object state;
        public string operation;
    }
}

UPDATE:


Fixed implementation because the SynchronizationContext.Send method returned without having completely executed the operation. Thanks to Svick for pointing that out and Stephen Toub for the help fixing it.

Adventures in C#, .NET and Software Development in general