> 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
[quoted text clipped - 3 lines]
>
> I don't know in what way you're confused about the *syntax* ....

Signature
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
> 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 - 29 Nov 2007 20:05 GMT
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
[quoted text clipped - 4 lines]
> 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!

Signature
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
Barrie Wilson - 30 Nov 2007 00:00 GMT
> 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.
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 - 30 Nov 2007 01:02 GMT
Barrie,
>> 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,
[quoted text clipped - 23 lines]
> }
> }
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.
>> 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.)
[quoted text clipped - 5 lines]
> 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!

Signature
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
Barrie Wilson - 30 Nov 2007 01:39 GMT
> 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 ...