Re: No Equals on interfaces
From: David (dfoster_at_woofix.local.dom)
Date: 09/04/04
- Next message: David: "Re: HELP! Why is this XMLSerializer Code Wacked?"
- Previous message: Cor Ligthert: "Re: Code Security"
- In reply to: Herfried K. Wagner [MVP]: "Re: No Equals on interfaces"
- Next in thread: Herfried K. Wagner [MVP]: "Re: No Equals on interfaces"
- Reply: Herfried K. Wagner [MVP]: "Re: No Equals on interfaces"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 04 Sep 2004 06:31:48 -0700
On 2004-09-04, Herfried K. Wagner [MVP] <hirf-spam-me-here@gmx.at> wrote:
> * David <dfoster@woofix.local.dom> scripsit:
> It's interesting that C#'s object browser lists 'Object' as base class
> for interfaces which is definitely not true and thus misleading.
I don't disagree there, but I also don't consider the object browser
part of the language. Actually, I so seldom open the object browser
that I don't really have an opinion at all on whether the browser should
show usage or abstractions. I wonder if that's another common
difference between C# and VB developers?
> 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).
On the flip side, c# follows IL semantics here. You don't need a cast
in IL in this situation either. This is often true of differences in
the languages, C# tends to be closer to IL and the CLR.
> (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#.)
ACK (except for the personal preference :-)
<snip>
>> 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 see the C# decision here slightly differently. I think it has
something to do with the tendency of c/c++ developers to think of
language artifacts as being thin artificial layers over the "real"
objects. I mentioned before in another thread with you that when I see
virtual or Overridable, I immediately think of an actual vtable. I
think that's common among certain developers. When I see...
Public Sub (someVar as ISomeInterface)
I don't think someVar is an ISomeInterface, because such a thing can't
exist in the CLR (I even struggled on what to call it here: an
ISomeInterface instance, an ISomeInterface object, an ISomeInterface
entity?). Rather, I think of it as a reference to an instance of some
Object-derived class that implements ISomeInterface, and therefore it's
natural that this reference contains an Object vtable.
My difference with your construction above is I don't think I'd say that
"every variable holds..." when describing the difference here. I don't
think of variables as doing things, they're mere signifiers (where's
Umberto Eco when you really need him :-).
Again, just a different way of looking at things, and a different
language for modelling things, and I don't think one is objectively
better than the other.
>> 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.
You're right, declarative is the correct term. The fact that assigning
an object reference to a variable changes the state of the object that
the variable used to reference took me a long while to get my head
around. It's just not how I think of variable names working. Even
today I don't really *get* it, I just think of the underlying IL as my
model to understand what's going on.
<snip>
>>> 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.
Out of curiosity, how so?
My complaint with accessing shared members and fields through instance
variables isn't that it's confusing or inconsistent, but rather that
it's error prone. But this issue is well-trodden ground where the pros
and cons have been hashed out pretty thoroughly over many years and many
languages.
- Next message: David: "Re: HELP! Why is this XMLSerializer Code Wacked?"
- Previous message: Cor Ligthert: "Re: Code Security"
- In reply to: Herfried K. Wagner [MVP]: "Re: No Equals on interfaces"
- Next in thread: Herfried K. Wagner [MVP]: "Re: No Equals on interfaces"
- Reply: Herfried K. Wagner [MVP]: "Re: No Equals on interfaces"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
