What Does this Mean?

[Jonathan Wood]

I found the following class on the Web:

public class LoginRewriter : IHttpModule {

void IHttpModule.Dispose() { }

void IHttpModule.Init(HttpApplication app) {
app.AuthorizeRequest += new EventHandler(authorizeRequest);
}

.
.
.
}

Can someone tell me what this syntax means? Are these methods simply
exposing protected methods of the base class? If so, does that mean you
could do the following:

LoginRewriter lr = new LoginRewriter();
lr.Dispose();
lr.Init(...);

Thanks.

 

[Barrie Wilson]

LoginRewriter implements the interface IHttpModule; yes, you can call the
two methods implemented but there isn't a lot of implementation of Dispose()
here ...

 

[Jonathan Wood]

I'm not asking about what the class does. I'm trying to understand the
syntax. What is the purpose of:

void IHttpModule.Dispose() {}

In the class definition? It appears to override a derived method but appears
to override it with nothing. In C++, I'd just do that with Dispose() {}, but
don't see the usefullness of either.

 

[Peter Bromberg [C# MVP]]

It's not overriding anything. If IHttpModule implements IDisposable, that's
why you are looking at a do-nothing barebones implementation of the required
member.
--
--Peter
"Inside every large program, there is a small program trying to get out."
http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://www.blogmetafinder.com

 

[Barrie Wilson]

I'm not asking about what the class does. I'm trying to understand the
syntax. What is the purpose of:

void IHttpModule.Dispose() {}

In the class definition? It appears to override a derived method but
appears to override it with nothing. In C++, I'd just do that with
Dispose() {}, but don't see the usefullness of either.

Jon,

as you can see clearly enough, Dispose() here does absolutely nothing ...
its apparent "purpose" is to comply with the rules of the road; if you
implement an interface (IHttpModule in this case) you MUST provide an
implementation of all the methods in that interface ... the compiler demands
it

I don't know in what way you're confused about the *syntax* ....

you asked:

"Are these methods simply exposing protected methods of the base class?"

since the class you found (LoginRewriter) implemented IHttpModule, there
were no methods to "expose" .. there were two methods requiring
implementation and that's what the class author provided, albeit nominally

I'm assuming your confusion stems from not recognizing that IHttpModule is
an interface ... that uppercase "I" is normally a pretty strong clue ...

HTH

 

[Jonathan Wood]

Thanks. I'm coming from a C++ background and I just don't understand what
that syntax is doing.

 

[Jonathan Wood]

Barrie,

as you can see clearly enough, Dispose() here does absolutely nothing ...
its apparent "purpose" is to comply with the rules of the road; if you
implement an interface (IHttpModule in this case) you MUST provide an
implementation of all the methods in that interface ... the compiler
demands it

I don't know in what way you're confused about the *syntax* ....

My background is C++. I'm not familiar with declaring methods with the base
class name followed by a dot, and the method name.

So my guess is that you are saying that IHttpModule implements a
pure-virtual method Displose(), which the derived class must implement (even
if the implementation does nothing). But I would have thought that could be
accomplished without prefixing the method name with base class name.

you asked:

"Are these methods simply exposing protected methods of the base class?"

since the class you found (LoginRewriter) implemented IHttpModule, there
were no methods to "expose" .. there were two methods requiring
implementation and that's what the class author provided, albeit nominally

Doesn't it implement IHttpModule using inheritance? So I don't get why it's
not possible to provide some sort of access to base class methods that were
previously protected. Apparently, that's not happening here but I don't see
what your statement "there were no methods to expose" is based on.

I'm assuming your confusion stems from not recognizing that IHttpModule is
an interface ... that uppercase "I" is normally a pretty strong clue ...

In C++, it seemed like an interface was just a logical construct and was
really no different from a virtual class. Obviously, C# is different. Looks
like I don't get how. Yes, I understood the "I" prefix denoted an interface.

 

[Barrie Wilson]

My background is C++. I'm not familiar with declaring methods with the
base class name followed by a dot, and the method name.

the dotted notation is only to avoid naming conflicts .. you can define an
interface at file scope or class-nested, and you can use the visibility
modifiers

So my guess is that you are saying that IHttpModule implements a
pure-virtual method Displose(), which the derived class must implement
(even if the implementation does nothing). But I would have thought that
could be accomplished without prefixing the method name with base class
name.

IHttpModule implements nothing; it declares the method signatures and says,
if you use this interface, **you** must implement the methods, properties
and events in the interface

Doesn't it implement IHttpModule using inheritance? So I don't get why
it's not possible to provide some sort of access to base class methods
that were previously protected. Apparently, that's not happening here but
I don't see what your statement "there were no methods to expose" is based
on.

because, in effect, there is nothing to inherit other than the method
signatures ... if you looked at the source for IHttpModule, you'd see
something like:

interface IHttpModule
{
void Dispose();
void Init(HttpApplication context);
}

that's it .. so what kind of "access to base class methods" is meaningful in
any way?

In C++, it seemed like an interface was just a logical construct and was
really no different from a virtual class. Obviously, C# is different.
Looks like I don't get how. Yes, I understood the "I" prefix denoted an
interface.

interfaces and abstract classes share common ground, although a method in an
abstract class can have implementation; often you can take your choice of
which to use

interfaces are easy to understand in formal terms; in functional and
conceptual terms it takes a fair amount of work/time to fully grasp why they
exist and the ways they're useful ... I'm not fully there yet but I know you
have to get there if you're going to lay claim to anything resembling
"expertise" .. they're important, period.

I would recommend something to read but frankly I have seen nothing yet
which does a really good job covering the topic ... best bet I think would
be Jeff Richter's "CLR via C#" ... which is something you should own and
read in any case ... that said, there is of course a ton of material
available

Coming from C# you might also go to http://www.charlespetzold.com and look
for the link to his free PDF book written just for people coming from C++

 

[Jonathan Wood]

Barrie,

IHttpModule implements nothing; it declares the method signatures and
says, if you use this interface, **you** must implement the methods,
properties and events in the interface

Okay, so while an interface is similar to an inherited class, you're saying
the difference is that the interface cannot include any implementation.

And so where I asked about overriding a method, it is more accurate to say
implement since there is nothing to override.

The part that is still weird to me is that I must specify the name of the
base class when implementing a method defined in the base class. For now,
I'll just accept that I do.

interfaces are easy to understand in formal terms; in functional and
conceptual terms it takes a fair amount of work/time to fully grasp why
they exist and the ways they're useful ... I'm not fully there yet but I
know you have to get there if you're going to lay claim to anything
resembling "expertise" .. they're important, period.

I've been working with inheritance for many years, so I think I really do
have a good feel for the way interfaces are useful. It's primarily some of
the language differences that I get hung up on.

I would recommend something to read but frankly I have seen nothing yet
which does a really good job covering the topic ... best bet I think would
be Jeff Richter's "CLR via C#" ... which is something you should own and
read in any case ... that said, there is of course a ton of material
available

Coming from C# you might also go to http://www.charlespetzold.com and look
for the link to his free PDF book written just for people coming from C++

CLR via C# sounds interesting. I might take a look at that. (Of course, I
just installed VS2008 so I might want to wait for an update.)

Thanks!

 

[Barrie Wilson]

Barrie,

Okay, so while an interface is similar to an inherited class, you're
saying the difference is that the interface cannot include any
implementation.

correct ... none

And so where I asked about overriding a method, it is more accurate to say
implement since there is nothing to override.
right

The part that is still weird to me is that I must specify the name of the
base class when implementing a method defined in the base class. For now,
I'll just accept that I do.

no, I don't think that's true at all as any kind of general rule, but what
happens here? :

interface INickels
{
void cConvert();
}

interface IDimes
{
void cConvert();
}

class Currency : INickels, IDimes
{

void cConvert()
{
Console.WriteLine( "cConvert implementation");
// which one are we implementing? INickels.cConvert or
IDimes.cConvert ? do we care?
}
}

however, that WILL compile without error ... but I probably want:

void INickels.cConvert() { }

void IDimes.cConvert() { }

actually, I probably want to re-design my interfaces here ...

meanwhile, and this is important, look up "Explicit Interface Method
Implementation" in the docs ... when you get it all sorted out, let us
know; I just have not yet taken the time to capture all of the nuance ..
and probably should ... and probably should do it with some simple Winforms
code to observe the behavior

CLR via C# sounds interesting. I might take a look at that. (Of course, I
just installed VS2008 so I might want to wait for an update.)

there's virtually ZERO chance of seeing an update to the book; there's
virtually nothing new in the CLR post-VS2008 ... Richter was approached by
MSPress to do a "CLR via C++/CLI" book but that project was tossed .... so
if you're interested in the book, might as well order it ... there's more to
interfaces than we've talked about here and that he does talk about in the
book ...

 

[Jonathan Wood]

Barrie,

no, I don't think that's true at all as any kind of general rule, but what
happens here? :

interface INickels
{
void cConvert();
}

interface IDimes
{
void cConvert();
}

class Currency : INickels, IDimes
{

void cConvert()
{
Console.WriteLine( "cConvert implementation");
// which one are we implementing? INickels.cConvert or
IDimes.cConvert ? do we care?
}
}

Yes, I understand what you are saying here. I believe the code I posted only
implemented a single inheritance so I'm not sure why it specified the base
class. I guess, if nothing else, the base class name is always optional.

there's virtually ZERO chance of seeing an update to the book; there's
virtually nothing new in the CLR post-VS2008 ... Richter was approached by
MSPress to do a "CLR via C++/CLI" book but that project was tossed .... so
if you're interested in the book, might as well order it ... there's more
to interfaces than we've talked about here and that he does talk about in
the book ...

Okay, I appreciate the info. I've got a stack of books on ASP.NET and some
C#, but none that focus on the CLR in a broader way. Might be useful.

Thanks!

 

[Barrie Wilson]

Yes, I understand what you are saying here. I believe the code I posted
only implemented a single inheritance so I'm not sure why it specified the
base class. I guess, if nothing else, the base class name is always
optional.

don't think that's quite right either, Jon ... actually, the MS docs
indicate that using the explicit, fully-qualified name is something you
rarely need to do and should avoid ... I have not fully sorted it out at
this point because it's yet to bite me anywhere tender

from the docs:
Avoid implementing interface members explicitly without having a strong
reason to do so.
Understanding explicit implementation requires an advanced level of
expertise. For example, many developers do not know that an explicitly
implemented member is publicly callable even though its signature is
private. Because of this, explicitly implemented members do not appear in
the list of publicly visible members. Explicitly implementing a member can
also cause unnecessary boxing of value types.

Okay, I appreciate the info. I've got a stack of books on ASP.NET and some
C#, but none that focus on the CLR in a broader way. Might be useful.

it is ... it's a useful book ...