Classes vs namespaces

[sergey-shandar]

C# doesn't have typedefs so it's hard to define the same type for specific API version and Latest namespaces. However, there is a workaround for this issue if we use classes instead of namespaces.

• old code

  namespace Service._2017_01_01
  {
   interface IOperation
   {
   }
   class Model
   {
   }
  }
  
  namespace Service.Latest
  {
   // a lot of problems here to define/redefine types from _2017_01_01 namespace
  }

• new code

  namespace Service
  {
    public abstract class _2017_01_01
    {
        interface IOperation
        {
        }
        class Model
        {
        }   
    }
  }
  
  namespace Service
  {
    public abstract class Latest : _2017_01_01
    {
    }
  }

  Usage

  using Service;
  Latest.Model model = new Latest.Model();

[devigned]

@markcowl, @johanste and @fearthecowboy thoughts on this way of expressing the C# API rather than with namespaces? Thoughts?

@jianghaolu and @anuchandy thoughts from the Java side? I think this might be preferable to the long namespaces. Thoughts?

[johanste]

In general, modeling through classes rather than namespaces gives you more flexibility in C#. Namespaces are a purely compile-time construct.

[sergey-shandar]

Another example

abstract class MyCompanyProfile : Service._2017_01_01
{
}

MyCompanyProfile.Model model = new MyCompanyProfile.Model();

[johanste]

@sergey-shandar, please, let's keep profiles as something that we (Microsoft) define. It is not an arbitrary grouping of stuff that 3rd parties put together (or am I misinterpreting the name class name in your example ? :))

[sergey-shandar]

@johanste Ok. You are not misinterpreting the name of the class. I was thinking about how other people may use it internally. I agree, this could be not a recommended way to use Azure SDK.

[devigned]

@sergey-shandar what do you think about extending this model to reflect the same scenarios as the current set of samples?

Feel free to completely replace the existing .NET code if you like. We could keep these in two different branches and you could use more applicable namespaces (rather than Service).

Looks cool!

[sergey-shandar]

@devigned yes, I plan to convert the existing samples when I have time.

[devigned]

@sergey-shandar I know you probably have other things going on, but if you can gather a bit of time to expand this, I think it would really help the group. Thx, man!

[devigned]

@jianghaolu and @anuchandy call number two for thoughts from the Java side?

[sergey-shandar]

@devigned I've got one problem to use the current set of samples. The samples don't have project files so I could validate that the code is valid. IMHO, we need to provide project files. After that, we and others can play with it and make sure it works with the current C# compiler.

[devigned]

@sergey-shandar just create a branch and burn the existing .net code to the ground. You can do with the new branch as you'd like.

[sergey-shandar]

@devigned I've updated the PR.

Assumptions:

1. Each API version of a swagger produces one DLL/NuGet package. Azure SDK/profile is a set of such DLLs/NuGet packages.
2. In this PR, I didn't try to solve the problem with shared types / duck typing. IMHO, it's another subject for discussion.

[devigned]

@sergey-shandar how would you use multiple profiles together with this strategy similar to how the multi-profile example does (side by side in the same application)?