VB vs C#

[Daniel O'Connell [C# MVP]]

Because they weren't necessarily identical for all implementations.
Suppose you had interfaces IMass, which has a property which returns the
mass of some item, and IWeight, which returns its weight. For class
GoldBrick, the implementations of those would be (mostly) identical. For
class HotAirBalloon, they'd be very different.

Yes, but I'd argue that IMass.Mass and IWeight.Weight, even if they work the
same in one situation, are entirely different and as a matter of
understanding using the same method to implement them isn't going to make
code that makes immediate sense. Although I can't think of a physics example
to qualify it. Once you do that, how do you seperate them again in a derived
class? You could say I don't like the conceptual muxing of different ideas
for convenience.

That's horribly oversimplified, of course, but it gives the general
idea.


What about implementations of non-public interfaces?

How often are non-public interfaces on public types a good idea? IMHO not
very often. You should be designing your architecture so that public
types contain mostly publically accessible functionality(or underlying
protected functionality for virtuality). However, that is my personal POV.

 

[Jeremy Todd]

Yes, but I'd argue that IMass.Mass and IWeight.Weight, even if they work the
same in one situation, are entirely different and as a matter of
understanding using the same method to implement them isn't going to make
code that makes immediate sense. Although I can't think of a physics example
to qualify it. Once you do that, how do you seperate them again in a derived
class? You could say I don't like the conceptual muxing of different ideas
for convenience.

Yes, this was discussed at length. In the end, we decided the pros
and cons slightly favored doing it my way, because the class hierarchy was
determined early on and we knew well in advance how each class would behave.

How often are non-public interfaces on public types a good idea? IMHO not
very often. You should be designing your architecture so that public
types contain mostly publically accessible functionality(or underlying
protected functionality for virtuality). However, that is my personal POV.

I don't follow. How is the use of non-public interfaces different from
non-public class members? Are you also opposed to private fields and
methods?

Jeremy

 

[cody]

Exception Filters:

Thats not entirely true, rethrowing an exception changes things. The primary
use(which in VB I consider a bit of a malformation) is to access the
exception without the change in the stack frame which occurs when you
actually enter a catch block. Also, rethrowing doesn't continue down the
catch handlers in the current try\catch set, while returning false from a
filter does.

Hm I have to agree now. I wonder why they didn't implement that in C# but
instead did it in VB?
Is there any reasoing behind that?

There is no real way to do it in C#. I have considered proposing the use of
the keyword class for this several times, I've yet to take the time to
implement it to test its fundamentals and see if it works.

Using the keyword class for other purposes than declaring a class was my
idea too a few weeks ago.
I wanted to use it to get the current type of the class:

static void Foo()
{
Type t = class
Console.Writeline("Iam declared in " + t);
}

Since GetType() is not available in static methods and hardcoding the class
via typeof(MyClass) is errorprone and confusing,
I find using "class" here is completely fine.

 

[Daniel O'Connell [C# MVP]]

Hm I have to agree now. I wonder why they didn't implement that in C# but
instead did it in VB?
Is there any reasoing behind that?

Best I've seen was from Eric Gunnerson, said something about it being
possible but that it didn't offer anything so they hadn't decided to do it
yet.

Using the keyword class for other purposes than declaring a class was my
idea too a few weeks ago.
I wanted to use it to get the current type of the class:

Yes, I remember. It was actually what finally gave me the bit of syntax I
needed for deciding on this.

static void Foo()
{
Type t = class
Console.Writeline("Iam declared in " + t);
}

I would rather see typeof(class) over just assigning class.

Since GetType() is not available in static methods and hardcoding the
class
via typeof(MyClass) is errorprone and confusing,
I find using "class" here is completely fine.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Jon Skeet [C# MVP]]

Well, Cody's reasons for disliking them didn't apply to VB.NET. What
don't you like about them, if I may ask?

General readability. There seems absolutely no need for it, and it
makes the context of a statement harder to see.

 

[Daniel O'Connell [C# MVP]]

Yes, this was discussed at length. In the end, we decided the pros
and cons slightly favored doing it my way, because the class hierarchy was
determined early on and we knew well in advance how each class would
behave.


I don't follow. How is the use of non-public interfaces different from
non-public class members? Are you also opposed to private fields and
methods?

Merely that they are interfaces. Its not so much a necessity as a goal I
strive to reach. I don't like to implement internal interfaces on public
classes, I'd rather rely on managers\factories and implement the interfaces
there and write the public classes without interfaces designed for internal
usage.
I also do my best to avoid designs which rely on internal members(I can't
think of the VB keyword for this, but assembly only access). They are a
nessecery evil in many cases, but something I always look for other ways
around. I don't mean that protected methods or private method(which usually
are helpers for public or protected methods) shouldn't exist, just that when
possible an interface should strive to be public and if a class can't expose
all its externally required behaviour publically there is probably a better
design available. However, this is a guideline I try to follow, not a
steadfast rule; I have written more than one internal interface\method in my
lifetime.

 

[Cor Ligthert]

Hi Jon,

General readability. There seems absolutely no need for it, and it
makes the context of a statement harder to see.

Although we agree this one completely, is this the same as using distinction
between upper and lowercase in C derived languages (and a lot more older
languages).

You are not obligated to use it.

Cor

 

[Jon Skeet [C# MVP]]

Although we agree this one completely, is this the same as using distinction
between upper and lowercase in C derived languages (and a lot more older
languages).

You are not obligated to use it.

That's never a good enough reason, IMO - if a feature is present,
people *will* use it, and like it or not, we don't always read code
that we've written ourselves.

 

[Cor Ligthert]

Hi Jon,

There is a very simple question in the VB.language group, almost everybody
was busy with it.
There is this sentence in.
dialogresult = me.show

My answer was this is not possible, when you want to do that it should be
with a new created form and a showdialog.

I did not understand how he would do this. Now he says he got the program
from someone else and it is to complex for him to read. I think there is
something in that program as.
\\\
Shadows Sub Show()
Dim frm As New Form2
Dim result As DialogResult
result = frm.ShowDialog()
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
Me.Hide()
Me.Show()
Me.Button1.Parent.Show()
End Sub
///

I told that if this is true that he was working in my idea, as I call them,
by the
maker obfuscated program.

Maybe it is not this code or something (I see now that it should be minimal
a function with a return of the result) however than you are talking about
the "with". Which what I said we agree. (second time in two days)



Cor

 

[Cor Ligthert]

I hope you understand the last row of this message, I see now, that I
corrected it to often.

The meaning is.
Maybe it is not exactly this code what is made (I see now too that it should
be minimal function with a return of the result)

However if it is this kind of code why should we than talk about the "with"/

Cor

 

[cody]

Using the keyword class for other purposes than declaring a class was my

Yes, I remember. It was actually what finally gave me the bit of syntax I
needed for deciding on this.

I would rather see typeof(class) over just assigning class.

Yes thats what I meant, I just forgot the typeof().

 

[Jon Skeet [C# MVP]]

There is a very simple question in the VB.language group, almost everybody
was busy with it.
There is this sentence in.
dialogresult = me.show

My answer was this is not possible, when you want to do that it should be
with a new created form and a showdialog.

What was not possible? Sorry, you haven't said what the actual question
was...

I did not understand how he would do this. Now he says he got the program
from someone else and it is to complex for him to read. I think there is
something in that program as.
\\\
Shadows Sub Show()
Dim frm As New Form2
Dim result As DialogResult
result = frm.ShowDialog()
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
Me.Hide()
Me.Show()
Me.Button1.Parent.Show()
End Sub
///

I told that if this is true that he was working in my idea, as I call them,
by the maker obfuscated program.

Maybe it is not this code or something (I see now that it should be minimal
a function with a return of the result) however than you are talking about
the "with". Which what I said we agree. (second time in two days)

I'm afraid I really didn't follow any of that... what point were you
trying to make again?

 

[Jon Skeet [C# MVP]]

I hope you understand the last row of this message, I see now, that I
corrected it to often.

The meaning is.
Maybe it is not exactly this code what is made (I see now too that it should
be minimal function with a return of the result)

However if it is this kind of code why should we than talk about the "with"/

If *what* is this kind of code?

I believe that With promotes less readable code, and therefore C# is
better without it. Just because you *can* write unreadable code in any
language doesn't mean that the language should encourage you to do so.

 

[Cor Ligthert]

What was not possible? Sorry, you haven't said what the actual question

was...

In a normal form
dialog result = me.show

Therefore I figured how it could been done. And I think it can be done with
this kind of code (I have shorten it for you)

Shadows function Show() as DialogResult
Dim frm As New Form2
return frm.ShowDialog()
End Sub

However this is weird in my opinion and add nothing, therefore I told what
are we talking about when people are even doing things like this.

Cor