Comments on On Designing Good Libraries -- Part III

Good
discussion
on part III, here are my comments:"urn:schemas-microsoft-com:office:office" />

 

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.