Re: No Equals on interfaces

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Herfried K. Wagner [MVP] (hirf-spam-me-here_at_gmx.at)
Date: 09/04/04 

Date: 04 Sep 2004 10:27:08 +0200

* David <dfoster@woofix.local.dom> scripsit:
>>>> None of the methods you can access from C#
>>>> are useful because they are all instance members and interfaces cannot
>>>> be instantiated.
>>>
>>> I'm not sure I understand what you're saying here. C# interprets iref
>>> above as being an instance of some sub-type of Object that also
>>> implements X. Whatever else iref may be, we know that it's a
>>> System.Object, and therefore the methods of System.Object are available.
>>>
>>> I'm not sure what you mean when you say these methods aren't useful. Why
>>> not?
>>
>> The OP's sample IMO didn't make sense. The methods are useful in
>> matters of objects/classes, but not in matters of interfaces only, as
>> shown in the OP's sample.
>
> The word "useful" still seems out of place here, but I see the point
> you're getting at.

OK.

It's interesting that C#'s object browser lists 'Object' as base class
for interfaces which is definitely not true and thus misleading. So,
it's actually C# that puts a semantic on interfaces that differs from the
semantics put on them in general .NET terminology. Interfaces are no
classes, and C# wants to tell me that they are, because interfaces
cannot inherit from a class ('Object' in this case).

(Just to make that clear: I respect that C# uses a different way to
handle interfaces, and I think it's good that there are many differences
between C# and VB.NET. But personally, I don't like the solution taken
by C#.)

>> Providing the methods of the 'Object' class
>> waters down the semantics of interfaces because interfaces do not
>> provide these methods.
>
> Hmmm. I must admit, I don't really have much of a preference one way or
> another. I can't really think of a way that either could lead to error,
> and that's the only real measure of these things to me.

:-)

> What's interesting (to me, at least) is that the C# way makes a bit
> more sense to me, and I'm more of a C# than VB programmer, but the more
> ardent VB defenders here greatly prefer the VB way. I don't think
> that's just language partisanship, it makes me think that the designers
> chose correctly here, and the choices reflect some underlying themes of
> the two languages.

Full ACK! There are certain cases where I like the way C# handes things
better, but in this case, I vote for the VB.NET solution. Nevertheless
I can understand the thought behind the C# way, "Every variable holds a
reference to an object or a null reference, thus the members provided by
the 'Object' class should be available for every variable". That's not
a bad idea, but it shows that for C#ies the /variable/ has other
semantics than in VB.NET, and that variables are more important than
general definitions of "interface" and "class".

> I only have very vague and ambiguous ideas on what those themes are,
> though. VB does tend to treat variable names and declarations as more
> important entities than does C#. I'm thinking of the way that implicit
> events bind to variable names and not to objects in VB

Do they? There is nothing implicit for events in VB. You will have to
use 'AddHandler' or 'RemoveHandler' which is very similar to the
approach taken in C#, or use 'WithEvents' + 'Handles' which is
declarative, but not implicit.

> while in C# the variable is simply front-end syntax representing a
> real object. In this case, to c# everything is an instance of some
> class and therefore an object, while to VB the underlying object is
> ignored in favor of the immediate declaration.

That's true.

>> I often hear people complaining about VB making shared members available
>> through instance variables. That complies with VB.NET's semantic of
>> shared variables.
>
> Yeah, I'd be one of the people complaining. I think that was a horrible
> decision, but that's neither here nor there.

I like the decision because I think it perfectly fits into the VB.NET
language. I would not like that to work in C#. C# and VB.NET are for
different people... 

-- 
 M S   Herfried K. Wagner
M V P  <URL:http://dotnet.mvps.org/>
 V B   <URL:http://dotnet.mvps.org/dotnet/faqs/>

Relevant Pages

  • Re: Generics Question
    ... I think I understand what you've misunderstood. ... interfaces to do the same semantic thing ("maintain a list of stuff" so ... The thing is, the feature that generics brings to the table, isn't this ... it's rather that it enables such semantics *in* ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Some questions about inheritance
    ... Abstract classes do have method signatures that defines the ... semantics of the actual implementation of the method by a sub-class. ... Delegation and Composition are two ways of extending behavior. ... by several interfaces or an interface composing/aggregating behavior ...
    (comp.object)
  • Re: Some questions about inheritance
    ... Abstract classes do have method signatures that defines the ... semantics of the actual implementation of the method by a sub-class. ... Delegation and Composition are two ways of extending behavior. ... by several interfaces or an interface composing/aggregating behavior ...
    (comp.object)
  • Re: Some questions about inheritance
    ... My take on your query is this: a) Abstract classes do have method signatures that defines the semantics of the actual implementation of the method by a sub-class. ... Delegation and Composition are two ways of extending behavior. ... by several interfaces or an interface composing/aggregating behavior ...
    (comp.object)
  • Re: devd limitations / automounting removable storage
    ... We might skip the devfs layer since it's probably implicit in the ... The thing about implicit stuff is that it move knowledge about what is ... rather than once newbus has attached an xl0. ... network interfaces are available for all drivers in the tree after ...
    (freebsd-arch)