By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,783 Members | 1,347 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,783 IT Pros & Developers. It's quick & easy.

C# 3.0 new language features

P: n/a
In C# 3.0 there will be radical additions:

(#) "select, from, where" keywords allowing to query from SQL, XML,
collections, and more (Language integrated query (LINQ)) - >>Can
appreciate
(#) Object initialization : Customer c = new Customer();
c.Name="James"; becomes Customer c = new Customer { Name="James" }; -
Can appreciate

(*!!*) Lambda expressions : listOfFoo.Where(delegate(Foo x) { return
x.size>10;}) becomes listOfFoo.Where(x => x.size>10);
(*!!*) Local variable type inference: var x = "hello"; is
interchangeable with string x = "hello";
(*!!*) Anonymous types : var x = new { Name = "James" }
(*!!*) Extension methods (adding methods to classes by including the
this keyword in the first parameter)
(*) C# 3.0 was unveiled at the PDC 2005, and a Preview, with
specifications is available From the MSDN Page (MSDN).

To me it looks like C# is including features (*!!*) that will enable
people to write unreable code. I cannot appreciate why these changes
are necessary. Can anybody convince me otherwise please?

May 17 '06 #1
Share this Question
Share on Google+
33 Replies


P: n/a
S Chapman,

See inline (I've rearranged the items a little):
(#) Object initialization : Customer c = new Customer();
c.Name="James"; becomes Customer c = new Customer { Name="James" }; -
Can appreciate

Same here.
(*!!*) Lambda expressions : listOfFoo.Where(delegate(Foo x) { return
x.size>10;}) becomes listOfFoo.Where(x => x.size>10);
Well, it's just shorthand. Personally, I like it, as typing some of the
other stuff is unwieldy. You don't HAVE to use it.
(*!!*) Local variable type inference: var x = "hello"; is
interchangeable with string x = "hello";
I agree that in this instance, it is unexcusable to use it. I would
slap someone who used var in a place where the type was known. However, in
the case where you don't know the return type (when you do a query and it
returns a projection (new anonymous type), you need some way of indicating
that there is something there you are working with, you just don't know
what).
(*!!*) Anonymous types : var x = new { Name = "James" }
This is essential for projections (for example, when you have a table in
SQL Server with three columns, and you select just two of them, that's a
projection). You need a way of easily creating new types.
(*!!*) Extension methods (adding methods to classes by including the
this keyword in the first parameter)
I'm a little wary about this myself. In my opinion, MS could have done
a better job with this, since they kind of dilute the definition of a type
now.
(#) "select, from, where" keywords allowing to query from SQL, XML,
collections, and more (Language integrated query (LINQ)) - >>Can
appreciate


While not all of the features are perfect (extension methods), or have
the potential to be used in the wrong way (var), if you look at the above
query language enhancements, you begin to see that they are all necessary
for enabling the above.

I remember when I saw this a long time ago, when the language
enhancements were presented, and then you see the query enhancements. You
have this "a-ha" moment that hits you like a ton of bricks when you figure
out how it is all interconnected.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
May 17 '06 #2

P: n/a
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
(*!!*) Extension methods (adding methods to classes by including the
this keyword in the first parameter)


I'm a little wary about this myself. In my opinion, MS could have done
a better job with this, since they kind of dilute the definition of a type
now.


I think extension methods will be fine (and indeed very useful) if MS
improves the syntax for including them. The current (well, last time I
looked) way of doing it was horrible in terms of it not being obvious
what was going on.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 17 '06 #3

P: n/a
Nicholas Paldino [.NET/C# MVP] wrote:
S Chapman,

See inline (I've rearranged the items a little):
(#) Object initialization : Customer c = new Customer();
c.Name="James"; becomes Customer c = new Customer { Name="James" };
-
Can appreciate
Same here.


I don't like it but it might be that it looks a bit messy (IMHO)
(*!!*) Lambda expressions : listOfFoo.Where(delegate(Foo x) { return
x.size>10;}) becomes listOfFoo.Where(x => x.size>10);


Well, it's just shorthand. Personally, I like it, as typing some
of the other stuff is unwieldy. You don't HAVE to use it.


I welcome these lambda expressions as writing the delegates is indeed
troubling a lot of people.
(*!!*) Anonymous types : var x = new { Name = "James" }


This is essential for projections (for example, when you have a
table in SQL Server with three columns, and you select just two of
them, that's a projection). You need a way of easily creating new
types.


though every time you should realize that writing a typed class for
this is essentially better than using var for this. As 'var' makes it
easy (no class to write) it might be people will fall into this trap
and have a hard time reading the code they wrote (or others wrote)
simply because it's var all over the place.
(*!!*) Extension methods (adding methods to classes by including the
this keyword in the first parameter)


I'm a little wary about this myself. In my opinion, MS could
have done a better job with this, since they kind of dilute the
definition of a type now.


See them as processing methods for a type you can't alter. Like find
methods on a collection type which doesn't have a find method. For this
purpose they're excellent. I first had the assumption they were
actually injecting code into the class so you could add an override to
a method which wasn't overriden in the class, but IMHO that's not
possible. In a way this is unfortunate as it would have made adding
code for validation etc. easier without having to write the code inside
the class, or perhaps in a farfetched scenario: AOP.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
May 17 '06 #4

P: n/a
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com>
wrote:
(*!!*) Local variable type inference: var x = "hello"; is
interchangeable with string x = "hello";


I agree that in this instance, it is unexcusable to use it. I would
slap someone who used var in a place where the type was known.


I personally find it annoying to repeat myself particularly where types
with generic arguments are required. I don't find things like:

---8<---
Dictionary<string,Pair<string,int>> x = new
Dictionary<string,Pair<string,int>>(StringComparer .Ordinal);
--->8---

better than

---8<---
var x = new Dictionary<string,Pair<string,int>>(StringComparer .Ordinal);
--->8---
(*!!*) Extension methods (adding methods to classes by including the
this keyword in the first parameter)


I'm a little wary about this myself. In my opinion, MS could have done
a better job with this, since they kind of dilute the definition of a type
now.


True, but at least they permit a form of extending an interface without
breaking it everywhere - something like the once-suggested "default
implementation" in an interface. I think they could be a little
"undiscoverable" from simply eyeballing the code, though - they are a
feature that requires good tool support and strong conventions.

-- Barry

--
http://barrkel.blogspot.com/
May 17 '06 #5

P: n/a
Barry,

See inline:
> (*!!*) Local variable type inference: var x = "hello"; is
> interchangeable with string x = "hello";
I agree that in this instance, it is unexcusable to use it. I would
slap someone who used var in a place where the type was known.


I personally find it annoying to repeat myself particularly where types
with generic arguments are required. I don't find things like:

---8<---
Dictionary<string,Pair<string,int>> x = new
Dictionary<string,Pair<string,int>>(StringComparer .Ordinal);
--->8---

better than

---8<---
var x = new Dictionary<string,Pair<string,int>>(StringComparer .Ordinal);
--->8---


I don't agree with this. You can use the using statement, like so:

// Let's assume Sp is short for String-Pair
using SpDictionary = System.Collections.Generic.Dictionary<string,
System.Collections.Generic.Pair<string,int>>;

And then:

SpDictionary x = new SpDictionary(StringComparer.Ordinal);
> (*!!*) Extension methods (adding methods to classes by including the
> this keyword in the first parameter)


I'm a little wary about this myself. In my opinion, MS could have
done
a better job with this, since they kind of dilute the definition of a
type
now.


True, but at least they permit a form of extending an interface without
breaking it everywhere - something like the once-suggested "default
implementation" in an interface. I think they could be a little
"undiscoverable" from simply eyeballing the code, though - they are a
feature that requires good tool support and strong conventions.


I don't have a problem with them extending the interface, it's the way
that it is called makes it so ambiguous. If they had a different
convention, I would like it much more.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

-- Barry

--
http://barrkel.blogspot.com/

May 17 '06 #6

P: n/a
var x = "hello"

Are we going back to vb 4.- ?
It looks like we are starting to circle around the code-globe
what happened to type safety... launched into dark matter.

SA
"S Chapman" <s_*********@hotmail.co.uk> wrote in message
news:11**********************@j73g2000cwa.googlegr oups.com...
In C# 3.0 there will be radical additions:

(#) "select, from, where" keywords allowing to query from SQL, XML,
collections, and more (Language integrated query (LINQ)) - >>Can
appreciate
(#) Object initialization : Customer c = new Customer();
c.Name="James"; becomes Customer c = new Customer { Name="James" }; -
Can appreciate

(*!!*) Lambda expressions : listOfFoo.Where(delegate(Foo x) { return
x.size>10;}) becomes listOfFoo.Where(x => x.size>10);
(*!!*) Local variable type inference: var x = "hello"; is
interchangeable with string x = "hello";
(*!!*) Anonymous types : var x = new { Name = "James" }
(*!!*) Extension methods (adding methods to classes by including the
this keyword in the first parameter)
(*) C# 3.0 was unveiled at the PDC 2005, and a Preview, with
specifications is available From the MSDN Page (MSDN).

To me it looks like C# is including features (*!!*) that will enable
people to write unreable code. I cannot appreciate why these changes
are necessary. Can anybody convince me otherwise please?

May 17 '06 #7

P: n/a
MSDN <sq**********@hotmail.com> wrote:
var x = "hello"

Are we going back to vb 4.- ?
It looks like we are starting to circle around the code-globe
what happened to type safety... launched into dark matter.


Type safety is still very much intact. "var" just means that the type
of the variable is inferred from the compile-time type of the RHS of
the assignment.

I'm not saying I like it, but it doesn't remove type safety at all.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 17 '06 #8

P: n/a
Here is a video which shows many of those features in action. It is
fairly impressive.

http://channel9.msdn.com/showpost.aspx?postid=114680

May 17 '06 #9

P: n/a
"Nicholas Paldino [.NET/C# MVP]" wrote:
Barry Kelly wrote:

---8<---
var x = new Dictionary<string,Pair<string,int>>(StringComparer .Ordinal);
--->8---


I don't agree with this. You can use the using statement, like so:

// Let's assume Sp is short for String-Pair
using SpDictionary = System.Collections.Generic.Dictionary<string,
System.Collections.Generic.Pair<string,int>>;

And then:

SpDictionary x = new SpDictionary(StringComparer.Ordinal);


The trouble with this is it leads to lots of local names for the same
type, which may get out of sync with one another (maybe a different name
is used in a different location). I also think it's less readable,
because you can no longer see the actual type of x - you have to hunt
for the using declaration.

-- Barry

--
http://barrkel.blogspot.com/
May 17 '06 #10

P: n/a
To me it looks like C# is including features (*!!*) that will enable
people to write unreable code.


You've been able to write completely unreadable code in C# since
version 1, so that's nothing new. I prefer to look at how and when the
new features are useful, not how they can be abused (which most
features can be).
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
May 17 '06 #11

P: n/a
>> var x = "hello"
Are we going back to vb 4.- ?


Do not confuse "'var" with Object. "var" is just a compiler trick, to
have it deduce, at compile-time what the type is:
object x = 1234; // boxed
Console.WriteLine(x.GetType().Name); // prints "Object"
x = "ABCD"; // OK.

var y = 1234; // not boxed
Console.WriteLine(y.GetType().Name); // prints "Int32"
y="ABCD"; // compile-time syntx error.

May 17 '06 #12

P: n/a
That's good stuff.

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------

"Chris Dunaway" <du******@gmail.com> wrote in message
news:11**********************@38g2000cwa.googlegro ups.com...
Here is a video which shows many of those features in action. It is
fairly impressive.

http://channel9.msdn.com/showpost.aspx?postid=114680

May 17 '06 #13

P: n/a

Barry Kelly <ba***********@gmail.com> wrote:
I personally find it annoying to repeat myself particularly where types
with generic arguments are required. I don't find things like:

---8<---
Dictionary<string,Pair<string,int>> x = new
Dictionary<string,Pair<string,int>>(StringComparer .Ordinal);
--->8---

better than

---8<---
var x = new Dictionary<string,Pair<string,int>>(StringComparer .Ordinal);
--->8---


Some sense in that, but IMO they placed the type inference in
the wrong place.

Why not allow:

Dictionary<string,Pair<string,int>> x = new(StringComparer.Ordinal);

or

Dictionary<string,Pair<string,int>> x = new
babe(StringComparer.Ordinal);

or whatever keyword seems appropriate.

This would keep with the style of typed declarations, yet relieve the
programmer of some finger- and eyestrain.

May 17 '06 #14

P: n/a
Ole,

The var is needed because of anonymous types, which are needed for
projections, which are needed for the query operations.

If you make an anonymous type, then you need var.

I agree though, they should allow that syntax in the language (where you
can just have new, and not the type name, but have it in the declaration).
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Ole Nielsby" <ol*********@snailmail.dk> wrote in message
news:uw**************@TK2MSFTNGP04.phx.gbl...

Barry Kelly <ba***********@gmail.com> wrote:
I personally find it annoying to repeat myself particularly where types
with generic arguments are required. I don't find things like:

---8<---
Dictionary<string,Pair<string,int>> x = new
Dictionary<string,Pair<string,int>>(StringComparer .Ordinal);
--->8---

better than

---8<---
var x = new Dictionary<string,Pair<string,int>>(StringComparer .Ordinal);
--->8---


Some sense in that, but IMO they placed the type inference in
the wrong place.

Why not allow:

Dictionary<string,Pair<string,int>> x = new(StringComparer.Ordinal);

or

Dictionary<string,Pair<string,int>> x = new
babe(StringComparer.Ordinal);

or whatever keyword seems appropriate.

This would keep with the style of typed declarations, yet relieve the
programmer of some finger- and eyestrain.

May 17 '06 #15

P: n/a
James,

Thank you for the enlightenment.

SA
<ja**********@gmail.com> wrote in message
news:11*********************@u72g2000cwu.googlegro ups.com...
var x = "hello"
Are we going back to vb 4.- ?


Do not confuse "'var" with Object. "var" is just a compiler trick, to
have it deduce, at compile-time what the type is:
object x = 1234; // boxed
Console.WriteLine(x.GetType().Name); // prints "Object"
x = "ABCD"; // OK.

var y = 1234; // not boxed
Console.WriteLine(y.GetType().Name); // prints "Int32"
y="ABCD"; // compile-time syntx error.

May 17 '06 #16

P: n/a
Jon,

Thank you the lesson.

SA
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
MSDN <sq**********@hotmail.com> wrote:
var x = "hello"

Are we going back to vb 4.- ?
It looks like we are starting to circle around the code-globe
what happened to type safety... launched into dark matter.


Type safety is still very much intact. "var" just means that the type
of the variable is inferred from the compile-time type of the RHS of
the assignment.

I'm not saying I like it, but it doesn't remove type safety at all.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

May 17 '06 #17

P: n/a
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:%2****************@TK2MSFTNGP04.phx.gbl...
(*!!*) Local variable type inference: var x = "hello"; is
interchangeable with string x = "hello";


I agree that in this instance, it is unexcusable to use it. I would
slap someone who used var in a place where the type was known. However,
in the case where you don't know the return type (when you do a query and
it returns a projection (new anonymous type), you need some way of
indicating that there is something there you are working with, you just
don't know what).


This has me very troubled. There is already a solution for this in C# 1.0.
It's called boxing (System.Object and reflection). I thought we dismissed
the variant (which is essentially how I read "var") to go to hell? But if
"var" here is strongly typed at compile-time, I don't mind that so much
because it would be "seen" in its true type during reflection, rather than
as a boxed object.

Still, this "solution" is just for the sake of laziness. This was introduced
for the sake of LINQ / C-Omega to do database lookups without doing a manual
look-up on the field type. I don't think it to be appropriate for a
programmer to not be required to know exactly what field type is being
brought back.
Jon
May 17 '06 #18

P: n/a
"Ole Nielsby" <ol*********@snailmail.dk> wrote:
Some sense in that, but IMO they placed the type inference in
the wrong place.

Why not allow:

Dictionary<string,Pair<string,int>> x = new(StringComparer.Ordinal);

This would keep with the style of typed declarations, yet relieve the
programmer of some finger- and eyestrain.


Just to add: as I'm sure you know, the type of expression trees is
usually annotated from the bottom up, for good reasons. C++ has set a
wonderful example in what happens to a language when it is designed with
no concerns for implementation difficulties.

This 'var' is something I've added to my own (functional) languages: an
immutable placeholder for an expression so it can in turn be reused,
turning an expression tree into a dag. It works well, and I'm delighted
to see it in C#.

-- Barry

--
http://barrkel.blogspot.com/
May 17 '06 #19

P: n/a
"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.net> wrote:
Still, this "solution" is just for the sake of laziness. This was introduced
for the sake of LINQ / C-Omega to do database lookups without doing a manual
look-up on the field type. I don't think it to be appropriate for a
programmer to not be required to know exactly what field type is being
brought back.


In many ways, I find that the arguments against 'var' strongly
reminiscent of the arguments in favour of hungarian notation. The
semantic meaning of the code should be visible by reading it.

Fields and properties may be declared screenfuls and even files away
from where they are used, yet these days one expects that people will
know what they represent even though they don't have an alphabet soup
attached any more labeling their types. 'var' does exactly the same
thing for local variables. It makes perfect sense to me.

-- Barry

--
http://barrkel.blogspot.com/
May 17 '06 #20

P: n/a

"Barry Kelly" <ba***********@gmail.com> wrote in message
news:r9********************************@4ax.com...
"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.net> wrote:
Still, this "solution" is just for the sake of laziness. This was
introduced
for the sake of LINQ / C-Omega to do database lookups without doing a
manual
look-up on the field type. I don't think it to be appropriate for a
programmer to not be required to know exactly what field type is being
brought back.


In many ways, I find that the arguments against 'var' strongly
reminiscent of the arguments in favour of hungarian notation. The
semantic meaning of the code should be visible by reading it.


I disagree. Visual Studio makes an inference at design time what a type
variable is and allows the coder to identify that type when hovering,
invoking dot-notation, or accessing its definition. Unless it's smart enough
to find this inference at design time (rather than at compile-time), this
immediate inference will be lost.

Jon
May 18 '06 #21

P: n/a
y"S Chapman" <s_*********@hotmail.co.uk> wrote:
(*!!*) Lambda expressions : listOfFoo.Where(delegate(Foo x) { return
x.size>10;}) becomes listOfFoo.Where(x => x.size>10);
I've been programming in functional languages a lot, where we use
these, and half the time they're unreadable and the other half they
make things enormously more clear. (how? mainly because the function
definition becomes local rather than at top level, so there are fewer
entities in your code, fewer top-level methods or functions).
(*!!*) Local variable type inference: var x = "hello"; is
interchangeable with string x = "hello";
Unreadable? I'd say the opposite. It'll be like Visual Basic and
Javascript, and wonderful. At the moment I write stuff like this,

SortedList<string,List<int>> x=new SortedList<string, List<int>>();

and it will become

var x = new SortedList<string, List<int>>();

(*!!*) Anonymous types : var x = new { Name = "James" }


I think this solves the horrid problem of object-oriented languages
that you can't return a tuple easily. If you want to write a function
that returns (int,int,string), i.e. a x-y coordinate and a label, then
you have to create a new struct/class. And wrap its fields up in
properties. And write a constructor. And provide an implementation for
Equals and GetHashCode and == and !=. And then construct it and assign
the fields. Yuck.

I actually did this in practice. I wrote my first prototype in F#, a
functional language, where I did return that (x,y,string) anonymous
tuple. And it took 1 line. Then I turned it into clean object-oriented
C# that obeyed FxCop and all the good programming practices of C#, and
it became 150 lines long.


So for all of these changes, I think they'll allow elegant concise
solutions to problems. Because they're more concise they have the
potential to be more readable. And they also have the potential to be
less readable. Good developers will use them in the first case, bad
developers will use them in the second case.

It'll maybe let Python programs program in C# more easily.
--
Lucian
May 18 '06 #22

P: n/a
Jon Davis wrote:

"Barry Kelly" <ba***********@gmail.com> wrote in message
news:r9********************************@4ax.com...
"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.net> wrote:
Still, this "solution" is just for the sake of laziness. This was
introduced
for the sake of LINQ / C-Omega to do database lookups without doing a >> manual look-up on the field type. I don't think it to be appropriate for a
programmer to not be required to know exactly what field type is

being >> brought back.

In many ways, I find that the arguments against 'var' strongly
reminiscent of the arguments in favour of hungarian notation. The
semantic meaning of the code should be visible by reading it.


I disagree. Visual Studio makes an inference at design time what a
type variable is and allows the coder to identify that type when
hovering, invoking dot-notation, or accessing its definition. Unless
it's smart enough to find this inference at design time (rather than
at compile-time), this immediate inference will be lost.


Always think ahead of what might be when you don't have your
super-duper helper tools available to read simple ascii code. If I
paste a piece of code in an email or blogpost, I'd like to have it to
be readable. This also speeds things up when reading code inside
vs.net. Because: do you hover over every variable in your code to
verify if it has the type you THINK it has? I bet you don't (as all of
us don't). It's human nature: "I think it has that type because <insert
assumed reason here>", as humans like to assume things.

That said, I don't think hungarian coding is the silver bullet for
giving that readability, as I've written large pieces of code in
hungarian coding style and after I've left it some years ago I haven't
really find myself wondering what type a variable is, basicly because
variable NAMES are more important and hungarian coding has a
disadvantage as well: what to pick for acronyms for variables of a
custom class type of along name (m_arrmecEntities ?? member variable
which is an array of MyEntityClass types. I don't think that's useful)

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
May 18 '06 #23

P: n/a
"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.net> wrote:
"Barry Kelly" <ba***********@gmail.com> wrote in message
news:r9********************************@4ax.com...
In many ways, I find that the arguments against 'var' strongly
reminiscent of the arguments in favour of hungarian notation. The
semantic meaning of the code should be visible by reading it.


I disagree. Visual Studio makes an inference at design time what a type
variable is and allows the coder to identify that type when hovering,
invoking dot-notation, or accessing its definition. Unless it's smart enough
to find this inference at design time (rather than at compile-time), this
immediate inference will be lost.


Another thing about var: it will help (ever so slightly) in writing a
form of generic code:

---8<---
var parts = GetCollectionOfStuff(x, y, z);
foreach (var part in parts)
{
Fiddle(part);
Frob(part);
}
--->8---

Here, the type of collection returned by GetCollectionOfStuff() may
change in the future, and if Frob() & Fiddle() also change, this
algorithmic code won't need to be modified.

I know, I'm stretching it a bit. However, a lot of working code has been
written in Python and Ruby, using dynamic typing, so I don't think that
eyeballing the source to see the semantic operations is much harder
without explicit type annotations. And this way, static typing is still
preserved.

I've always thought that the main argument for static typing is catching
errors at compile time, not for cluttering the code with the
implementation details of semantic quantities.

-- Barry

--
http://barrkel.blogspot.com/
May 18 '06 #24

P: n/a
S Chapman schrieb:
In C# 3.0 there will be radical additions:

[lots of stuff I don't need]
Can it do MyObjectType X(MyConstructorparameters);
and create an object on the stack where I don't
have to do all this dispose stuff because the destructor
gets called as soon as it gets wiped off the stack?

Lots of Greetings!
Volker
--
For email replies, please substitute the obvious.
May 18 '06 #25

P: n/a
Volker Hetzer <fi****************@ieee.org> wrote:
S Chapman schrieb:
In C# 3.0 there will be radical additions:

[lots of stuff I don't need]
Can it do MyObjectType X(MyConstructorparameters);
and create an object on the stack where I don't
have to do all this dispose stuff because the destructor
gets called as soon as it gets wiped off the stack?


A struct implementing IDisposable and used inside a "using" block does
all you need.

-- Barry

--
http://barrkel.blogspot.com/
May 18 '06 #26

P: n/a
Barry Kelly schrieb:
Volker Hetzer <fi****************@ieee.org> wrote:
S Chapman schrieb:
In C# 3.0 there will be radical additions:

[lots of stuff I don't need]
Can it do MyObjectType X(MyConstructorparameters);
and create an object on the stack where I don't
have to do all this dispose stuff because the destructor
gets called as soon as it gets wiped off the stack?


A struct implementing IDisposable and used inside a "using" block does
all you need.

Actually no. IDisposable is not what *I* need, it's what
*every caller* of my objects "needs".
The point of the suggestion above is that I implement it once
and no caller can do it wrong anymore. Especially, the caller
should IMHO not have to differentiate between objects
and non-objects. With dispose he has to.

Lots of Greetings!
Volker
--
For email replies, please substitute the obvious.
May 18 '06 #27

P: n/a
Volker Hetzer <fi****************@ieee.org> writes:
Actually no. IDisposable is not what *I* need, it's what
*every caller* of my objects "needs".


You could always work around this problem by using finalizers. Of
course, finalizers have their downsides (e.g. all finallizable objects
are not created on generation 0 but generation 1 or 2 if I remember
correctly).

Best Regards,
Martin
May 18 '06 #28

P: n/a
Volker Hetzer <fi****************@ieee.org> wrote:
Actually no. IDisposable is not what *I* need, it's what
*every caller* of my objects "needs". The point of the suggestion above is that I implement it once
and no caller can do it wrong anymore.
Even if you had C++ destructor semantics on automatic variables of type
struct, such structs could be allocated as a field in a heap-allocated
object - so the users of the class would still have to care.

The idiom in C# for C++ RAII is "using". If client code isn't doing
that, it's their problem. It's as simple as that.
Especially, the caller
should IMHO not have to differentiate between objects
and non-objects. With dispose he has to.


I don't quite understand what you refer to. Do you mean a distinction
between value types and reference types? Or between objects which
require disposal and those which don't?

-- Barry

--
http://barrkel.blogspot.com/
May 18 '06 #29

P: n/a
Martin Carpella schrieb:
Volker Hetzer <fi****************@ieee.org> writes:
Actually no. IDisposable is not what *I* need, it's what
*every caller* of my objects "needs".


You could always work around this problem by using finalizers. Of
course, finalizers have their downsides (e.g. all finallizable objects
are not created on generation 0 but generation 1 or 2 if I remember
correctly).

Yes, that would often work, but as far as I know there's no guarantee
that the garbage collector gets called.
When you have to hand back a license token this is not nice.

Lots of Greetings!
Volker
--
For email replies, please substitute the obvious.
May 18 '06 #30

P: n/a
Barry Kelly schrieb:
Volker Hetzer <fi****************@ieee.org> wrote:
Actually no. IDisposable is not what *I* need, it's what
*every caller* of my objects "needs".
The point of the suggestion above is that I implement it once
and no caller can do it wrong anymore.


Even if you had C++ destructor semantics on automatic variables of type
struct, such structs could be allocated as a field in a heap-allocated
object - so the users of the class would still have to care.

I think a workable idea would be to have a reference to that object
on the stack (if it is declared locally). Then, when the runtime system
clears the stack, it knows that an object is a local one and can be
destroyed immediately. That way MS perhaps wouldn't have to break
much of their CLR.

The idiom in C# for C++ RAII is "using". If client code isn't doing
that, it's their problem. It's as simple as that.
Especially, the caller
should IMHO not have to differentiate between objects
and non-objects. With dispose he has to.


I don't quite understand what you refer to. Do you mean a distinction
between value types and reference types? Or between objects which
require disposal and those which don't?

Both. I think the matter of disposal shouldn't depend on the internals
of an object but on the way of creation.
So, If I write myType X; I shouldn't have to look up what the type is
in order to figure out whether I need to do a X=new mytype(); too.
Somehow I feel more comfortable with C++'s way of letting the user decide
how he wants the object to be managed (automatically on the stack
or manually with new/free).
On the other hand, GC can be very fast, so maybe the best of both worlds
is a way to declare objects locally and have them managed deterministically
*and* a new/free where free calls the finalizer or dispose (if there is one).
Then one can lose the reference and gc takes care of the rest.

Lots of Greetings!
Volker
--
For email replies, please substitute the obvious.
May 19 '06 #31

P: n/a
Volker Hetzer <fi****************@ieee.org> wrote:
I think a workable idea would be to have a reference to that object
on the stack (if it is declared locally). Then, when the runtime system
clears the stack, it knows that an object is a local one and can be
destroyed immediately. That way MS perhaps wouldn't have to break
much of their CLR.
But what if the object isn't local - what if it's added to a collection,
or passed to some other routine in another assembly, not visible at
compile time?

My point is that you can't force users to dispose of the objects, and
that the idiom for this requirement in C# is the "using" statement.
Especially, the caller
should IMHO not have to differentiate between objects
and non-objects. With dispose he has to.


I don't quite understand what you refer to. Do you mean a distinction
between value types and reference types? Or between objects which
require disposal and those which don't?

Both. I think the matter of disposal shouldn't depend on the internals
of an object but on the way of creation.
I can only agree to a limited extent. I think that it's fairly rare that
objects which are commonly allocated on the stack have implementation
changes that toggle whether or not they implement "IDisposable".

Database connections, file streams, windows (and thus controls), it is
obvious that these things, by their semantics, require disposal, since
they deal with persistent connections to things external to the
application's memory space.

If some object or component is so complex that one doesn't immediately
know whether or not it will require disposal, then it should probably
implement IDisposable anyway for future proofing, and callers similarly
should manage its lifetime by controlling the calling of
IDisposable.Dispose().

Most objects aren't so monolithic, though. They either deal immediately
with the external world, or they don't. One uses using() or some
ownership mechanism for the first, and lets GC take care of the others.
Somehow I feel more comfortable with C++'s way of letting the user decide
how he wants the object to be managed (automatically on the stack
or manually with new/free).


Sure. I only wished to point out that in many ways it isn't a real
distinction, because it's normally obvious which objects need disposal
and which don't.

-- Barry

--
http://barrkel.blogspot.com/
May 19 '06 #32

P: n/a
Volker Hetzer <fi****************@ieee.org> writes:
Yes, that would often work, but as far as I know there's no guarantee
that the garbage collector gets called.
When you have to hand back a license token this is not nice.


As long as the AppDomain is shut down properly, finalizers will get
called but with a timeout. So yes, there is no guarantee they really get
called.

But even if you have C++-like stack semantics destructors will not necessarily
get called, e.g. if the process is canceled externally, power failures,
etc.

C++/CLI gets very close to the stack semantics of C++, well, the memory
is not released on exit of the variable's scope, but at least Dispose()
is called.

Best regards,
Martin
May 22 '06 #33

P: n/a
Martin Carpella schrieb:
Volker Hetzer <fi****************@ieee.org> writes:
Yes, that would often work, but as far as I know there's no guarantee
that the garbage collector gets called.
When you have to hand back a license token this is not nice.
C++/CLI gets very close to the stack semantics of C++, well, the memory
is not released on exit of the variable's scope, but at least Dispose()
is called.

I think I'll have a look at this. If the programming overhead relative
to C# is manageable, maybe I'll use this instead.

Thanks a lot for your help!
Volker
--
For email replies, please substitute the obvious.
May 22 '06 #34

This discussion thread is closed

Replies have been disabled for this discussion.