|
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.
|
|
|
|
|
Don Kackman wrote: Sweet! You owe me $20!
 Um, we didn't shake on it.
Don Kackman wrote: All of the above mixed in with loops, branches and other objects being used.
I agree with that 100%, but I blame the programmer for it rather than the language construct is what I'm trying to get at.
Don Kackman wrote: 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.
Most of the time I used it, it wasn't the fault of VB's verbosity but rather I wanted to clean my code up a bit with longer object naming, etc. I reckon to each his own, but methinks the abuse of it is the real issue more than having it available to use when needed.
|
|
|
|
|
Jeremy Falcon wrote: I reckon to each his own, but methinks the abuse of it is the real issue more than having it available to use when needed.
True.
But you still owe me $20!
|
|
|
|
|
Don Kackman wrote: But you still owe me $20!
Um, talk to my assistant about that. What? Who's my assistant? Oh, um, yeah, ask my assistant about that one too.
|
|
|
|
|
I'm actually a little surprised that C# 3 didn't see something like it already (aside from the new member initialization syntax.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
