VB to C#

[Jon Davis]

Well *I* want what VB.NET supports in terms of multiple indexed
properties.

I'm very glad that the feature is missing in C#, for the reason I described
and repeat below. C# strives to be clear and concise, not feature-packed. C#
doesn't have the My. namespace, either, but again, it's the wrong audience
for that sort of thing.

What pisses me off is the introduction of "var" in the next version;
although it is useful, it is so completely contrary IMO to the direction C#
intended to go from the beginning.

Jon
It makes
it much less difficult to get confused about whether you're accessing an
object's indexer or an object's property's indexer, i.e. ...

myObject.myIndexedProp["three"]

.... is "myIndexedProperty" above implemented as an indexed myIndexedProp
property of myObject, or is it the Item property of an object that is
returned by a non-indexed myIndexProp property of myObject??

By forcing C# to use only one optional property as an indexed property,
understanding the code becomes significantly less ambiguous and awkward.
Exposing that single indexed property as "this[...]" made the property bound
to the object by its explicit name.
<<

 

[Jon Skeet [C# MVP]]

I'm very glad that the feature is missing in C#, for the reason I described
and repeat below. C# strives to be clear and concise, not feature-packed.

That's fine when it doesn't make it significantly harder to use. In the
situations I've wanted to use named indexers, the solution is much
worse than the cost to readability of using named indexers would have
been.

How often would it actually matter which you were using though? To give
a parallel example, using the standard naming conventions of .NET it's
not clear whether MyType.Something is a reference to a static
(readonly, one would hope) field, a static property, or a constant -
but how often is that a problem? If you need to know, it's not hard to
find out.

C# doesn't have the My. namespace, either, but again, it's the wrong
audience for that sort of thing.

That feels like a different ball of wax to me, but it's hard to say
exactly why.

What pisses me off is the introduction of "var" in the next version;
although it is useful, it is so completely contrary IMO to the direction C#
intended to go from the beginning.

Perhaps, but that's not necessarily a bad thing. The whole of LINQ is
somewhat contrary to the direction C# originally intended to go in.
Arguably generics and anonymous methods are pretty complicated compared
with C# 1.0. "var" certainly leaves a nasty taste in my mouth, but I'
mnot sure what a better solution to the problem posed would be.

 

[Jon Davis]

That's fine when it doesn't make it significantly harder to use. In the
situations I've wanted to use named indexers, the solution is much
worse than the cost to readability of using named indexers would have
been.

That's probably because the C# way to accomplish much of what you're trying
to do is achieved with methods. Exposing parameterized getters and setters
has no benefit being in the form of a property rather than a method. The
only exception to this is when the object itself is a collection which is
why the single indexer works fine. If you want multiple indexers on an
object, you know that you can overload the indexer with different parameter
arguments, right?

How often would it actually matter which you were using though? To give
a parallel example, using the standard naming conventions of .NET it's
not clear whether MyType.Something is a reference to a static
(readonly, one would hope) field, a static property, or a constant -
but how often is that a problem? If you need to know, it's not hard to
find out.

Finding out is one thing, reading other people's code is another matter.
This is why I hate the new "var". If I can't look at code and know what
things are then and there or what belongs to whom, the language has proven
itself more costly than the feature given to the original coder.

Perhaps, but that's not necessarily a bad thing. The whole of LINQ is
somewhat contrary to the direction C# originally intended to go in.
Arguably generics and anonymous methods are pretty complicated compared
with C# 1.0. "var" certainly leaves a nasty taste in my mouth, but I'
mnot sure what a better solution to the problem posed would be.

It would be nice if var was an IDE feature and not a language feature. Once
you hit 'Enter', the IDE should look up the data type of the referenced
database column and replace the 'var' with a suitable strongly typed
declaration rather than "infer". The whole "inference" thing makes me sick
to my stomach. That was THE premise of the VB6 variant, I don't care what
people say about the variant being more than that. And believe me, I even
rewrote a Variant object in C# just to prove the point.

http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=2854&lngWId=10

Jon

 

[Barry Kelly]

It would be nice if var was an IDE feature and not a language feature. Once
you hit 'Enter', the IDE should look up the data type of the referenced
database column and replace the 'var' with a suitable strongly typed
declaration rather than "infer". The whole "inference" thing makes me sick
to my stomach. That was THE premise of the VB6 variant, I don't care what
people say about the variant being more than that.

I don't agree with you - Variant is a bag that can contain any value, a
run-time feature, while 'var' is a type inference compile-time feature.

Static type safety gives a language three things, in my rough
classification below:

1) a fairly weak mechanical verifier,
2) extra information for compilation (e.g. optimization, typeof),
3) extra information for design-time (e.g. correct intellisense)

'var' doesn't break 2 & 3 since it's built on type inference, and it
only breaks 1 in so far as it allows the programmer to omit redundant
declarations, but still doesn't reduce actual verification. The program
is no less type safe due to 'var'.

Variant is something else entirely. It breaks 1 since the compiler can
no longer verify operations on variants, it breaks 2 since the compiler
can't prove the run-time type, and it breaks 3 since the editor can't be
sure about the compile-time type. Variant isn't built on inference.

I think that saying that 'var', a compile-time inference tool, is the
principle behind VB6's variant is, frankly, either ignorant or
dishonest.

-- Barry

 

[Jon Skeet [C# MVP]]

That's probably because the C# way to accomplish much of what you're trying
to do is achieved with methods. Exposing parameterized getters and setters
has no benefit being in the form of a property rather than a method.

It has the same benefits that normal properties do over GetXXX calls -
readability. I'd rather see:

myObject.BinaryData[index];

than

myObject.GetBinaryData(index);

in the same way that I like using dataTable.Rows[index] - the fact that
the DataTable exposes a single Rows property which allows more than
just indexing is a side issue here - there's a readability benefit
which is hard to achieve when you only have named properties with no
parameters.

The only exception to this is when the object itself is a collection which is
why the single indexer works fine. If you want multiple indexers on an
object, you know that you can overload the indexer with different parameter
arguments, right?

Yes, but that doesn't help when you want to make it clear what aspect
of an object you're accessing.

Finding out is one thing, reading other people's code is another matter.

But again, how often do you need to know? Do you find it a problem that
it's not always obvious whether you're accessing a static property or a
constant?

This is why I hate the new "var". If I can't look at code and know what
things are then and there or what belongs to whom, the language has proven
itself more costly than the feature given to the original coder.


It would be nice if var was an IDE feature and not a language feature. Once
you hit 'Enter', the IDE should look up the data type of the referenced
database column and replace the 'var' with a suitable strongly typed
declaration rather than "infer". The whole "inference" thing makes me sick
to my stomach. That was THE premise of the VB6 variant, I don't care what
people say about the variant being more than that. And believe me, I even
rewrote a Variant object in C# just to prove the point.

The point of "var" is that it lets you express things in code which you
*couldn't* do with explicit declarations, because you can refer to
types which are only generated by the compiler in the first place.
Without anonymous types (which are *so* useful in LINQ) I don't believe
"var" would have surfaced in the first place.

"var" is *not* the same thing as having a Variant type at all.

 

[Cor Ligthert [MVP]]

Jon,

Since the time of Basic/Pascal, there is in programming languages no
relation anymore between values and memoryplaces (let us not forget that
they were first as C was AFAIK too designed as student languages)..

For most professional programmers from before that time confrontated with
that it was awfull. We could not design and redesign the memory usage
anymore. Now it is standard and I think nobody is missing that because there
is memory enough.

However the variant stays for me one of the most awfull thing there are,
while I always have to think how many processing those, maybe in a
programming language simple declarations, needs.

Just my thought,

Cor

 

[Jon Skeet [C# MVP]]

Since the time of Basic/Pascal, there is in programming languages no
relation anymore between values and memoryplaces (let us not forget that
they were first as C was AFAIK too designed as student languages)..

For most professional programmers from before that time confrontated with
that it was awfull. We could not design and redesign the memory usage
anymore. Now it is standard and I think nobody is missing that because there
is memory enough.

However the variant stays for me one of the most awfull thing there are,
while I always have to think how many processing those, maybe in a
programming language simple declarations, needs.

But once again, "var" *isn't* anything like Variant. I wish people
would stop getting hung up with comparisons between the two ideas when
they're very different.

 

[Cor Ligthert [MVP]]

Jon Skeet,

But once again, "var" *isn't* anything like Variant. I wish people
would stop getting hung up with comparisons between the two ideas when
they're very different.

I had not the idea that there is one word "var" in my message.

That you have the same first name as Jon Davis does not mean that every
message from me is attended to you.



Cor

 

[Kevin Spencer]

I suspect that the "var" issue stems from the fact that
JavaScript/EcmaScript uses the keyword "var" to define a variant. The use of
the same term is probably unfortunate.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

Jon Skeet,

But once again, "var" *isn't* anything like Variant. I wish people
would stop getting hung up with comparisons between the two ideas when
they're very different.

I had not the idea that there is one word "var" in my message.

That you have the same first name as Jon Davis does not mean that every
message from me is attended to you.



Cor