On aliasing the Dispose name...
Michael
argues
that the guideline we have around using a customized name for the Dispose method
is a bad idea because it adds developer confusion. This is a reasonable argument, and
one that heavy hitters such as Jeffrey
Richter buy into as
well, so it is worth some careful thought.
I think the easiest way to
understand this issue is via an example, let’s take a look at the System.IO.FileStream
class… currently it is defined as:
public
class FileStream: Stream, IDisposable {
//all the normal
methods
void IDisposable.Dispose () {
//explicitly implemented
//close
the file handle, etc
}
public void Close ()
{
Dispose();
}
}
Notice that the Dispose method is
not public… it is explicitly
implemented on the class. This
means that the Dispose method can only be called directly when an instance of
the FileStream class is cast to IDisposable. We also provide Close() method that is
publicly accessible off the FileStream class.
FileStream s =
new FileStream (…);
s.Close();//
works great
s.Dispose();
//compile error
((IDisposable)
s).Dispose(); //works great
We use this combination in order
to:
1.
Meet the time honored expectation
that file related things are “Closed” not “Disposed”, etc. We did not want to force every developer
to learn the Dispose is just “our name for Close”…
2.
We wanted to enable FileStream to
plug into generic mechanisms for ensure deterministic finalization such as C#’s
using statement.
3.
We wanted only one way to
Close\Dispose a file in explicitly in code.
The
Jeff and
Michael camp would
rather see us have only the Dispose method (if my understanding is right). While that meets goals 2 and 3 outlined
above, I believe the fact that it fails 1 is a significant enough problem to
warrant the additional implementation complexity of our current story. I say implementation complexity because
I don’t believe that many users actually find any additional complexity with
this design. They just use Close()
and\or C#’s using support and have no problems.
That said, I have sympathy for the
argument and, like most features explicit implementation can be abused. As such we are working on a guideline
right now to help clear that up.
Suggestions always welcome!
