|
Nemanja Trifunovic wrote: VB = C# - curly braces - semicolons + Dim
I'm still happy to be a dinosaur too. Rawr!!
|
|
|
|
|
VB also supports an 'Optional' keyword. C#, for some reason supports only overloading and does not support the optional keyword.
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
All the world's a stage,
And all the men and women merely players.
They have their exits and their entrances;
And one man in his time plays many parts... --William Shakespeare
|
|
|
|
|
Yeah, that's a tough one to swallow coming from C++ as well. Although with a bit of prep work, you can kinda fake it by passing in an object and using initializers. IMHO, C# should build this into the compiler and just give us named parameters with default values...
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
That's pushing the envelope a bit far! "Optional" is really only useful in VB to simulate polymorphism, which C# already supports.
Public Sub MyExample(intLength As Integer, Optional intWidth As Integer)
' Some code
End Sub
-- C#
public void MyExample(Length as int)
{
}
public void MyExample(Length as int, Width as int)
{
}
http://mytechworld.officeacuity.com
|
|
|
|
|
I disagree:
public void MyExample( int length, optional int height = 0, optional int width = 0 )
{
}
is better (and clearer) than
public void MyExample( int length )
{
MyExample( length, 0 );
}
public void MyExample( int length, int height)
{
MyExample( length, height, 0 );
}
public void MyExample( int length, int width )
{
MyExample( length, 0, width );
}
public void MyExample( int length, int height, int width )
{
}
|
|
|
|
|
Why bother with a keyword? The compiler should be able to handle
public void MyExample( int length, int height = 0, int width = 0 ){
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
You are right. 'Optional' is just syntatic sugar that would make it more visible.
|
|
|
|
|
No - VB.NET has polymorhism too
Optional is mainly used for dealing with OLE Automation (particularily of Office apps) which have optional parameters....
But doesn't C# have a var keyword for that?
|
|
|
|
|
That's not polymorphism, that's overloading, and is entirely separate issue from default (optional) parameters - for example C++ supports both.
|
|
|
|
|
And here's why:
pane.YAxis.IsVisible = true;
pane.YAxis.Type = AxisType.Linear;
pane.YAxis.Scale.FontSpec.Size = 9;
pane.YAxis.Scale.FontSpec.IsAntiAlias = true;
pane.XAxis.IsVisible = true;
pane.XAxis.Type = AxisType.Date;
pane.XAxis.MajorTic.IsInside = false;
pane.XAxis.MajorTic.IsOpposite = false;
pane.XAxis.MinorTic.IsInside = true;
pane.XAxis.MinorTic.IsOpposite = true; Becomes:
with (pane.YAxis)
{
.IsVisible = true;
.Type = AxisType.Linear;
with (.Scale.FontSpec) { .Size = 9; .IsAntiAlias = true; }
}
with (pane.XAxis)
{
.IsVisible = true;
.Type = AxisType.Date;
with (.MajorTic) { .IsInside = false; .IsOpposite = false; }
with (.MinorTic) { .IsInside = true; .IsOpposite = true; }
}
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
I find your solution VERY hard to read! Specially the idea of allowing nested with's...I think that's a recipe for disaster and ugly code.
I don't think the time you save by typing less is worth the readability you give up, specially now a days that IntelliSense is so great. I rather Copy/Paste the object name, or create object references and deal with those directly, for example:
YAxis y = new YAxis();
y.IsVisible = true;
y.Type = AxisType.Linear;
y.Scale.FontSpec.Size = 9;
y.Scale.FontSpec.IsAntiAlias = true;
pane.YAxis = y;
I think we need to learn and leverage the tools we already have before asking for new ones, I'm surprised to see how most developers don't take the full advantage of VS or C# advanced features.
|
|
|
|
|
rickyvj wrote: I don't think the time you save by typing less is worth the readability you give up
Actually, it would save little if any typing. The win (for me anyway) comes in eliminating the "wall of text" - line after line of nearly identical property names. I'm looking for something closer to CSS-style syntax: <span style="font-weight: bold;">selector</span> { <span style="font-style: italic;">properties</span> } .
rickyvj wrote: IntelliSense is so great
IntelliSense reduces the amount of time it takes to create a dense block of chained properties, but does nothing to aid in reading the results later on. The example is taken from a bit of code i use for creating ZedGraph charts; originally, it was much, much longer, but i've eliminated most of it in favor of rule-based or metadata-based configuration after it became clear that maintaining such dense code was extremely error-prone.
rickyvj wrote: I think we need to learn and leverage the tools we already have before asking for new ones
That's... a bit silly. Like suggesting i should learn to use a paring knife more effectively before asking for a potato pealer, or memorize logarithm tables before asking for a pocket calculator. If a tool is useful, it should be built - anyone is free to not use it.
rickyvj wrote: I'm surprised to see how most developers don't take the full advantage of VS or C# advanced features.
I have several socket wrenches i've never used; they came in a set with several others that i use frequently. But if i ever do need them, they're ready and waiting...
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
With 2008 there is an an easier way to do what you suggest using the new constructors.
pane.YAxis = new YAxis{
IsVisible = true,
Type = AxisType.Linear,
Scale.FontSpec.Size = 9,
Scale.FontSpec.IsAntiAlias = true
};
Richard Green
|
|
|
|
|
Great, thanks!
See? This is what I mean by learning the tools you already have before asking for new ones!
|
|
|
|
|
rickyvj wrote: or create object references and deal with those directly, for example:
I'd rather something faster that's handled by the compiler.
Also, it seems your whole stance is based on you just don't like it and no reason outside of that.
|
|
|
|
|
Very much. It would greatly enhance a cleaner code.
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
All the world's a stage,
And all the men and women merely players.
They have their exits and their entrances;
And one man in his time plays many parts... --William Shakespeare
|
|
|
|
|
I agree. The With syntax is concise and terse. It actually aids readability and maintainability by reducing the number of times you have to type/past/whatever the same word, and that can only be a good thing. Particularly if you're working with sloppy coders who mix up statements that should be kept separate, and then go changing reference names and such. With a With block it's immediately obvious where the group reference starts and ends. It reduces duplication, which is always a Good Thing. Anyone who thinks otherwise is barking mad. The world is wrong, I am right, end of story...
|
|
|
|
|
I suppose with would need without anyway.
In my opinion, there should be no words-as-operators; all operators should be composed of non-alphabetic characters.
|
|
|
|
|
We could have:
string s;
myObject.
{
s = .ToString();
}
instead of
Dim s as String
With myObject
s = .ToString()
End With
|
|
|
|
|
In VB With isn't an operator. It's a block delimiter with an improvised local scope.
As in "With object" do stuff with object's properties, "End With"
I suppose in C# it'd end up like an if statement or a loop statement, a modifier for the {} brackets.
|
|
|
|
|
While it makes the code a bit easier to write, I find with makes code a bit harder to maintain or learn as you have to make sure to remember the object be referenced as you read through the code. This is especially true with poorly written code; with just makes overly long code blocks all the harder to sort out.
modified on Monday, October 6, 2008 1:01 PM
|
|
|
|
|
I'm assuming that the VB with is the same as the Turbo Pascal with , which I never used.
|
|
|
|
|
PIEBALDconsult wrote: the same as the Turbo Pascal with, which I never used
I used that a lot and liked it but that was in the early 1990s and I have not written a line of pascal in at least 15 years..
John
|
|
|
|
|
Don Kackman wrote: I find statements with with harder to read
$20 says it's mainly because you're not used to it. After using it for years I can say it's not that hard.
|
|
|
|
|
Jeremy Falcon wrote: $20 says it's mainly because you're not used to it. After using it for years I can say it's not that hard.
Sweet! You owe me $20!
I cut my teeth on VB3-6 and have seen (and used) my share of with statements. If common usage were limited to:
with myObject
.field1 = 0
.field2 = 1
end with
it's not so bad.
Unfortunately, over the lifetime of an app all too often you end up with
with myObject
.field1 = 0
if someBool then
.DoSomething
end if
[20 lines later]
.DoSomethingElse
[20 lines later still]
.field3 = .field1 + .field2
[at the bottom of a 500 line method with a bunch of other logic intertwingled]
end with
All of the above mixed in with loops, branches and other objects being used.
Having done plenty of both VB syntax and C style syntax development I think the with statement is really nothing more than a reaction to VB's excess verbosity, saving some keystrokes and sacrificing readability and maintainability.
|
|
|
|