Re: VB to C#

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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 Davis" <jon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> schreef in bericht
news:en2fF$c2GHA.3564@xxxxxxxxxxxxxxxxxxxxxxx

"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
news:MPG.1f766cc7858da15c98d480@xxxxxxxxxxxxxxxxxxxxxxx
Jon Davis <jon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
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.

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





.

Relevant Pages

  • Re: Public variables
    ... My own best practise by the way is to avoid the Dim keyword at class level wich is confusing about this. ... In old programming languages you could in fact only declare your variables fixed in your program in a kind of static way. ... Therefore you see in some older languages stil used for this Static, in fact a little bit outdated, as all data is relocatable stored in the memory your computer. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Best OS packages for Ruby?
    ... distribution, is there not a real chance you will end up with code that only ... If everyone's always whining about "No you can't take that feature out" ... programming languages and their libraries have to ...
    (comp.lang.ruby)
  • Re: Why C for operating systems
    ... you should keep in mind that operating systems have been ... high level programming languages. ... faster and have have craploads more memory. ... have reason to use other languages. ...
    (comp.programming)
  • Re: += in ada
    ... >feature of programming languages. ... And my point is that Ada already has it. ... it's a funny thing that the compiler might compile ...
    (comp.lang.ada)
  • Objects, Type, and OOP [Was: What is an object?]
    ... An "object" in C is basically a hunk of memory that can hold ... SIGPLAN-SIGACT symposium on Principles of programming languages" ... of classes "class objects". ... I believe there has been some influence of the OOP term ...
    (comp.lang.c)