Comments on On Designing Good Libraries — Part III

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


href="">Frans Bouma asks

reference type by value copied the reference

> class=commentbody>* 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
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">You are right in a way. style="mso-spacerun: yes">  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.  style="mso-spacerun: yes"> It is interesting to think about it this
way because reference types can also be passed by reference, which is different.

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

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
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">This is a good point, we should add
this to the guideline.

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

href="">Lawrence Oluyede has a similar response
to the pass a reference by value thing..

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”.

> class=commentbody>It’s a matter of terminology.



Bouck is pushing for using the underscore to prefix private fields. style="mso-spacerun: yes"> 

My policy is to not try to
standardize on internal coding conventions. style="mso-spacerun: yes"> 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


href="mailto:rickAT%20NOSPAMkinitos%20dot%20com">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


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. style="mso-spacerun: yes"> 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. style="mso-spacerun: yes">  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.

style="mso-spacerun: yes">  style="mso-spacerun: yes"> 

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. style="mso-spacerun: yes"> My personally opinion is that such a
feature would add complexity to the language and should be avoided. style="mso-spacerun: yes"> 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.


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.
style="FONT-FAMILY: 'Courier New'; mso-bidi-font-family: 'Times New Roman'">public
event Click; would be a good example.
The event handler specific the
contact receiver of the event have to honor. style="mso-spacerun: yes">  It is essentially a method signature and
should be of the form: <EventName>Handler… A good example would
style="FONT-FAMILY: 'Courier New'; mso-bidi-font-family: 'Times New Roman'">public
delegate ClickEventHandler (ClickEventArgs args);


href="mailto:kevinwAT%20NOSPAMi2%20dot%20co%20dot%20uk">Kevin Westhead also
provides a solid description of the complex issue of passing reference types by
reference or by value. style="mso-spacerun: yes">  

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

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


>void DoSomething(ref object

>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

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. style="mso-spacerun: yes"> Therefore I strongly suggest stay clear
of this concept in your public APIs.

style="MARGIN: 0in 0in 0pt"> 

Comments (3)

  1. Robi Khan says:

    I really have to disagree about the ‘I’ prefix for interfaces. Interfaces are not substantively different from types from the caller’s perspective. Yeah, you can’t construct them, but that’s true of abstract classes, or any class with a non-public constructor.

    What really needs a naming convention is structs vs. classes. Structs behave _very_ differently than objects w.r.t. boxing, copy semantics, performance etc. I often insert null arg checks or assertions in my code and am constantly annoyed when what I thought was an object reference turns out to be a value, causing a compile failure. Or worse yet, when something gets unexpectedly boxed or copied because it’s a value. These are truly substantive differences that should be apparent by looking at the source code. In Java it’s not a problem because there are only primitive value types. In C/C++ you always have ‘->’ and ‘*’ to distinguish refs and vals.

    Again, it’s probably to late to change, but I would suggest a prefix, like ‘V’, for structs. So you’d have VRect, VPoint etc, or a suffix like Value for RectValue, PointValue and so on.

    My rant for the day.