Good discussion on part III, here are my comments:

 

Frans Bouma asks

>A reference type by value copied the reference
>* Commonly used: public void Insert (object value) {..}
>I might be wrong, but 'value' in the example above is passed by reference since it's an object, am I right?

 

You are right in a way.  All reference types are passed by reference by default.  The way to think about this is that the reference itself (a memory address) is passed by value.   It is interesting to think about it this way because reference types can also be passed by reference, which is different.  

 

> Also, an important (IMHO ;)) thing about events is missing from the list (and from MS' documentation), which is: if object A exposes an event, and object B >subscribes on that event by defining a new event handler (A.Event += new EventHandler(name); ), and B goes out of scope it will not be garbage collected until >A is also garbage collected, because A holds a reference to a method in B

This is a good point, we should add this to the guideline.

 

Lawrence Oluyede has a similar response to the pass a reference by value thing..

>When you pass around value types you pass the value (the contained data) by default or if you specify ref you pass a reference (the address I guess) of the

> variable. This is what I call "passing a value type by value or by reference". When you pass around an object you don't pass its value but the address of the

> object location. This is what I call "passing the reference by value". As Brad stated there is another passing method that is passing the object by reference. In this

> situation you pass a reference of the reference (a pointer) and this is what I call "passing the reference by reference".
>It's a matter of terminology.

 

 

Michael Bouck is pushing for using the underscore to prefix private fields.  

My policy is to not try to standardize on internal coding conventions.  So as long as you follow the guidelines for publicly exposed identifiers (that is public and protected\Family btw) then you will get no push back from me.
BTW, the issue with CLS compliance should not be an issue if you are staying away from publicly exposed identifiers.

 

Rick Byers offers some particle reasons why simple getters are best. While I believe Rick and I are basically on the same wave-length, it is possible to error on the other side as well and avoid properties all together which would clearly be a mistake.

 

Kevin Dente is pushing back on having the “I” prefix on interfaces…. We did have hours and hours of debate about that one back in the day when we first came up with the guideline. In the end there are two compelling reasons for including the “I” prefix:
1) A nod to our COM heritage.  COM popularized this convention and given that the .NET Framework is a direct follow-on from COM, we thought it was worth acknowledging that and streamlining migration to the .NET Framework by following the COM convention.  Notice, Java didn’t follow this convention, IMHO this was the exact opposite: a snub of the COM heritage.

2) We felt that interfaces where substantively different from types that calling them out was important.  Interfaces are never directly constructed for example.  Having done some recent spelunking in the Java libraries, I must say that I miss the interface prefix there… it realy helps me categorize\sort types in my head and get a better picture for the concepts.

  

Kevin also raises a pretty common C# language design question about why the get and set on a property can’t have different accessibilities (one public and on protected for example). It is a very common feature request and the C# design time has considered a number of options of getting there, but to my knowledge they have not closed on one.  My personally opinion is that such a feature would add complexity to the language and should be avoided.  Conceptually properties are a single design element (yes, I know how they are really implemented at the CLR level…) just like methods or fields.  I think breaking that conceptual bond to the other elements should not be done lightly.  And, I think the “work-around” I outlined is actually pretty workable.

 

Thomas Freudenberg is asking about naming conventions for events… Events have several parts, let me see if I can outline them:

The event itself is the member on the class that you signup at to receive notifications, it should be named with a Verb as Thomas suggests.
public event Click; would be a good example.
The event handler specific the contact receiver of the event have to honor.  It is essentially a method signature and should be of the form: <EventName>Handler… A good example would be
public delegate ClickEventHandler (ClickEventArgs args);

 

Kevin Westhead also provides a solid description of the complex issue of passing reference types by reference or by value.   

>void DoSomething(object someValue)
>A copy of the handle to someValue on the managed heap is passed to DoSomething. This means that you can still change the state of the object via its properties

>and methods, but you cannot change the original handle. In otherwords, setting someValue to null in the callee will not null the original object that was passed by

>the caller.

>void DoSomething(ref object someValue)
>The original handle to someValue on the managed heap is passed to DoSomething. Setting someValue to null in callee will null the original object that was passed

>by the caller.

 

The only think I will add to this discussion is that clearly the notion of references by reference is quite confusing, for API designers, and more importantly our clients.  Therefore I strongly suggest stay clear of this concept in your public APIs.