Home > Archive > ASP .NET > November 2007 > What Does this Mean?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
What Does this Mean?
|
|
| Jonathan Wood 2007-11-25, 7:17 pm |
| 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);
}
| |
| Barrie Wilson 2007-11-25, 10:15 pm |
|
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" <jwood@softcircuits.com> wrote in message
news:eojT8Z6LIHA.484@TK2MSFTNGP06.phx.gbl...
>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.
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
| |
| Jonathan Wood 2007-11-25, 10:15 pm |
| 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.
--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Barrie Wilson" <bwilson@nowhere.com> wrote in message
news:13kjprgc19k1f7e@corp.supernews.com...
>
> 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" <jwood@softcircuits.com> wrote in message
> news:eojT8Z6LIHA.484@TK2MSFTNGP06.phx.gbl...
>
>
| |
| Peter Bromberg [C# MVP] 2007-11-25, 10:15 pm |
| 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
"Jonathan Wood" wrote:
> 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.
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
>
> "Barrie Wilson" <bwilson@nowhere.com> wrote in message
> news:13kjprgc19k1f7e@corp.supernews.com...
>
>
| |
| Barrie Wilson 2007-11-26, 4:28 am |
|
"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:uGROAr7LIHA.5244@TK2MSFTNGP03.phx.gbl...
> 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 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 2007-11-26, 7:21 pm |
| Thanks. I'm coming from a C++ background and I just don't understand what
that syntax is doing.
--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Peter Bromberg [C# MVP]" <pbromberg@yahoo.NoSpamMaam.com> wrote in message
news:CBE0A51E-5BB4-4F61-B969-E43F25E913D9@microsoft.com...[color=darkred]
> 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
>
>
>
> "Jonathan Wood" wrote:
>
| |
| Jonathan Wood 2007-11-26, 7:21 pm |
| 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 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.
--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
| |
| Barrie Wilson 2007-11-26, 7:21 pm |
|
"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:ObItvRFMIHA.3852@TK2MSFTNGP06.phx.gbl...
> 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 2007-11-29, 7:15 pm |
| 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!
--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
| |
| Barrie Wilson 2007-11-29, 7:15 pm |
|
"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:%23LsXCNsMIHA.4308@TK2MSFTNGP05.phx.gbl...
> Barrie,
>
[color=darkred]
> 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 2007-11-29, 10:13 pm |
| 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!
--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
| |
| Barrie Wilson 2007-11-29, 10:13 pm |
|
"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:%23x51DzuMIHA.5360@TK2MSFTNGP03.phx.gbl...
> 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 ...
|
|
|
|
|