Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Acbu

Acbu Acbu

Niner since 2008

  • Raja Krishnaswamy and Vance Morrison: CLR 4 - Inside Type Equivalence

    Wow. This sounds really great. Common embeded interface definitions is something I have often wished for this kind of thing in the past and this sounds like a really excellent implementation.

    On a related note I have another "problem" that I guess this tyep of approach might one day be able to solve?

    Like I suspect many people I now have a large library of extension methods which i commonly use embeded in a dll. Most of these are extermely simplistic but just make the code easier to read. Currently every app I write has to be shipped with a copy of the dll that implements these extension methods. However many small apps only use a very small number of these extension methods. In addittion new extension methods are often added. This results in lots of versions of this libary dll being distributed. In practice however these extenstions are really about cleaning up code syntax and the code will in effect evetualy be inlined. They are in effect a bit like code snippets. It would seem much better if these exensions were simply embbeded by the complier when used so i didnt need to ship a seperate big dll. Perhaps one day this technology might make that possible.

     

     

  • Eric Gunnerson - How do you design new features for C#?

    Some syntactic sugar?

    Instead of code like:
     {
     using (var a=new c())
        {
             using(var b=new d())
             {
                .....
             }
         }
    }

    why not simply allow the scope to be implied by the enclosing braces?
    {
     var x  = new myglocal();
     local var a = new c() ;  
     local var b = new d();
    }

    Also how about a  thread-safe null-checking dot operator .? to supplement the ?? operator.
    so 
    var x= (a!=null)?a.fn():null 
    can be shortend to
    var x = a.?fn();
    For value-types the return value could be up-converted to a nullbable type as required.
    int v = a?.MyIntFn() ?? mydefaultValue;
    Invoking events/delegates could also be supported as folows 
      myevent.?(sended,args);
    Removing one of the often -discussed current problems of how to achive this safely.

  • Eric Gunnerson - How do you design new features for C#?

    Fancy code refactoring with extentension interface implemenations

     I have been playing around with the wonderfull new extension methods, templates etc.
     You can do some great things with the new IEumerator<T> list constructs.
     One of the things i really like about these is that you can apply them consistently accross a number of different types.

     It seemed logical to do the same type of thing with trees however here-in lies a problem there is no consistantly used interfce such as IEnumerator upon which to base such extensions.
     You can of course create the same code multiple times each one for a different type, but this seems really messy and inefficient.
     
     What would be usefull would to provide allow extension interface implementations - a bit like a multiple inheritance extension.
     
     We could have something like:

        public interface ITreeBase<T>  // just a normal everyday interface
        {
            bool IsRoot();
            IEmumerable<T> GetChildren();
        }
       
        // Now say we want extension  methods to implement this inteface for a TreeNode we might have something like

       public static class TreeNodeExtn:ITreeBase<TreeNode>
       {
         public bool IsRoot(this TreeNode This)  { return false; }
            public IEmumerable<TreeNode> GetChildren(this TreeNode This)
            {
               return This.Nodes;
            }
       }

       // The above is ok - but we need to be specific about what class we are adding the inteface extension to.
       // Also it would be nice to simplify the syntax a bit. So we we might re-write this something like:
      
       public class TreeNodeExtn extends TreeNode :ITreeBase<TreeNode> // Note this is still just an Extension no real inheritence here
       {
         public bool IsRoot { get { return false;} }
            public IEmumerable<TreeNode> GetChildren()
            {
               return this.Nodes;
            }
       }
       
       OK so now we define this for some other types also as follows:
      
       public static class TreeViewExtn extends TreeView: ITreeBase<TreeNode>
       {
         public bool IsRoot { get { return true; }}
            public IEmumerable<TreeNode> GetChildren()
            {
               return This.Nodes;
            }
       }
       public static class XPathNavigatorExtn extends XPathNavigator: ITreeBase<XPathNavigator>  // note this is a static class with extension methods
       {
         public bool IsRoot { get {return false; }}
            public IEmumerable<XPathNavigator> GetChildren()
            {
               while(var v in this.Children()) yield return v.current;
            }
       }
      
      Now we can of course use these extension methods exactly as in before for items of one of the TreeNode,TreeView or XPathNavigator
      
      So next we would like to write some generic tree handling extension methods using our new extensions as follows
      
        public static class TreeBaseExtnMethods
       {
            public IEmumerable<T> Descendants<T>(this ITreeBase<T> This)
            {
               foreach(var v in This.Children())
               {
                   yield return v;
             foreach(var d in v.SelfAndDescendants())yield return d;
               }
            }
            public IEmumerable<T> FindDescendant<T>(this ITreeBase<T> This,Func<T,bool> fn)
            {
               foreach(var v in This.Children())
               {
                 if(fn(v)){ yield return v; yield break; }
                foreach(var d in v.SelfAndDescendants(fn))yield return d;
               }
            }
          .....
       }
      
       // OK looks nice but how will this work in practice.
       // The complier will compile the TreebaseExtn methods as before.
       // So for it to work the above functions actually need to be passed a class that implements ITreeBase<T>
       // To achive this the compiler simply creates an instance class of each of the extension classes (TreeNode,TreeView or XPathNavigator).
       // These class are simply container classes each one has exactly just one field "this" which refers to an instance of the object we are extending.
       // So for the first example it in effect complies as:
      
      public class TreeNodeExtn:ITreeBase<TreeNode>
       {
          prviate TreeNode This;
         public bool IsRoot { get { return false;} }
            public IEmumerable<TreeNode> GetChildren()
            {
               return This.Nodes;
            }
            public static implicit operator ITreeNodeExtn(TreeNode tn)
            {
             return new TreeNodeExtn { This=tn };
            }
            public static implicit operator  TreeNode(TreeNodeExtn tn)
            {
             return tn.This;
            }
       }
      
       // Lots of other nice stull you can do with the above... but thats for another day.