T
Tom
isSelected in big DataGrids is very time-consuming. I would be nice to have
a property with some kind of list of currently selected rows.
a property with some kind of list of currently selected rows.
J
Jon Skeet [C# MVP]
Tom said:
(I don't think this is particularly off-topic, by the way.)
Some changes I'd like to see:
1) Get rid of the lock statement, replace it with "using" and an
appropriate Disposable type. See
http://www.pobox.com/~skeet/csharp/threads/alternative.shtml
2) A way of declaring a variable as being private to a property
3) Java-like enums (they're really, really great
4) Classes being sealed by default
5) Changes to the behaviour of beforefieldinit:
http://www.pobox.com/~skeet/csharp/beforefieldinit.html
6) A simple way of declaring simple properties (i.e. properties which
just get/set values in the obvious way.) This could use suggestion 2...
7) In generics, I *think* the Java concept of '?' is useful, eg:
List<? extends ISomething> x = GetThisList();
foreach (ISomething : x)
{
...
}
I've tried similar things in C#, but haven't managed to get it to work
yet. (Other than that kind of thing, .NET generics are far superior to
Java generics.)
8) AOP
9) Design-by-contract
I'm sure there was something else, but I can't remember it right now...
R
Radek Cerny
I'm sure there was something else, but I can't remember it right now...
Multiple Inhertitance. (native in the CLR)
Multiple Inhertitance. (native in the CLR)
D
Daniel O'Connell [C# MVP]
3) Java-like enums (they're really, really great
Out of curiosity, what do you like about them over C# enums?
I personally stil want to see casting redesigned.
J
Jon Skeet [C# MVP]
Daniel O'Connell said:
They're more than just values - they're real objects. You can give the
enum methods, and override those methods, and give each enum value a
constructor, too.
Unfortunately I don't have time to go into how useful this can be right
now - but we're using them extensively on the project I'm working on at
the moment, and it's painful when we go back to C#...
Yes, I wouldn't mind that either.
C
cody
Some changes I'd like to see:
They could theoretically change the lock statement so that is internally
works exactly like your proposed solution but that could cause compatibility
problems, I think.
This would be a good idea.
yes they are more OO and more useful because you nearly always have to
associate humanfriendly and localizable names to the enum.
I do not agree with this one, because classes should alway be made
inheritable otherwise it wouldn't be really OO, if your class must not be
inheritable, due to security, compatibility or performance reasons you use
sealed but that should be a very rare exception, I never really needed it.
"any type with a static initializer or an explicit static constructor should
not (by default) be marked as beforefieldinit"
I do not agree with that. In almost all cases you do not care when exactly
the static fields are initialized, this is not worth the performance impact.
Having a attribute to specify the beforefieldinit is a great idea, Iam even
wondering if it would be possible to have tis attribute not per class but
per field, so the static field initializers are effectivly grouped in 2
static ctors - one with beforefieldinit, and one without.
You mean something like that:
public class Test
{
public property int Number;
}
which would create a property and a private variable named _number or
something like that.
If I understand it correctly this won't work in .NET. In .NET specialized
classes are difference classes that is, you cannot cast IList<string> to
IList<object>, specialized classes doesn't even share the same static
variables, each specialisation get their own. Also in Java you cannot use
primitives like int as type parameter (you can but then the system uses the
integer class which is an object) , therefore I believe it won't work in
..NET.
They could theoretically change the lock statement so that is internally
works exactly like your proposed solution but that could cause compatibility
problems, I think.
This would be a good idea.
3) Java-like enums (they're really, really great
yes they are more OO and more useful because you nearly always have to
associate humanfriendly and localizable names to the enum.
I do not agree with this one, because classes should alway be made
inheritable otherwise it wouldn't be really OO, if your class must not be
inheritable, due to security, compatibility or performance reasons you use
sealed but that should be a very rare exception, I never really needed it.
"any type with a static initializer or an explicit static constructor should
not (by default) be marked as beforefieldinit"
I do not agree with that. In almost all cases you do not care when exactly
the static fields are initialized, this is not worth the performance impact.
Having a attribute to specify the beforefieldinit is a great idea, Iam even
wondering if it would be possible to have tis attribute not per class but
per field, so the static field initializers are effectivly grouped in 2
static ctors - one with beforefieldinit, and one without.
You mean something like that:
public class Test
{
public property int Number;
}
which would create a property and a private variable named _number or
something like that.
If I understand it correctly this won't work in .NET. In .NET specialized
classes are difference classes that is, you cannot cast IList<string> to
IList<object>, specialized classes doesn't even share the same static
variables, each specialisation get their own. Also in Java you cannot use
primitives like int as type parameter (you can but then the system uses the
integer class which is an object) , therefore I believe it won't work in
..NET.
C
cody
I personally stil want to see casting redesigned.
What do you mean with that? What is wrong with casting in your eyes?
What do you mean with that? What is wrong with casting in your eyes?
B
Brian Gideon
I particularly liked items 1 and 4 in Jon's list.
I'm not entirely convinced that we need this, but in VB.NET you can
declare nested types in an interface. You cannot do this in C#.
I saw a post a long time ago by Eric Gunnerson who hinted at a
ReturnValueImportantAttribute. If the return value was ignored the
compiler would throw a warning or something. It would catch some
common errors when using immutable classes.
C# 2.0 will support lexical closures with anonymous methods, but
continuation handling is nonexistent. See
<http://pluralsight.com/blogs/dbox/archive/2005/04/27/7780.aspx> for
more information. I'm not necessarily advocating the addition of
continuation handling. I'm just pointing out that there has been some
chatter about it.
I'd like a method that counts the number of set bits in a bitfield that
would take full advantage of the JIT compiler's capability to generate
CPU specific instructions. Some CPUs have special instructions that
are significantly faster than portable techniques.
Brian
I'm not entirely convinced that we need this, but in VB.NET you can
declare nested types in an interface. You cannot do this in C#.
I saw a post a long time ago by Eric Gunnerson who hinted at a
ReturnValueImportantAttribute. If the return value was ignored the
compiler would throw a warning or something. It would catch some
common errors when using immutable classes.
C# 2.0 will support lexical closures with anonymous methods, but
continuation handling is nonexistent. See
<http://pluralsight.com/blogs/dbox/archive/2005/04/27/7780.aspx> for
more information. I'm not necessarily advocating the addition of
continuation handling. I'm just pointing out that there has been some
chatter about it.
I'd like a method that counts the number of set bits in a bitfield that
would take full advantage of the JIT compiler's capability to generate
CPU specific instructions. Some CPUs have special instructions that
are significantly faster than portable techniques.
Brian
D
Daniel O'Connell [C# MVP]
cody said:
Its syntactically and semantically messy, basically.
The syntactic problem is casting uses two entirely different operators. One
of which is unlike everythign else in the language(the normal ( ) casting),
which causes nasty ((Type)expression).Accessor() code, which is just
difficult to read. The syntax causes some difficulties parsing the language
at times(is (X) a type cast or a grouped expression?), and it is probably
the worst casting syntax of any major language, IMHO.
The semantic problem is there is no differentiation between *casting* and
*converting*. () has complex rules as to what happens. This makes
determining what a cast will actually do difficult.
Ideally I'd like to see syntax like C++ cast<Type>(expression),
convert<Type>(expression), but I'm sure other options exist.
J
Jon Skeet [C# MVP]
cody said:
Absolutely - the boat has sailed on this one. It's more what I'd like
to have seen from the start than what should be changed now.
The problem is that inheritance is very hard to really design for -
this is one of the reasons methods are non-virtual by default in C#. A
class which hasn't been designed for inheritance shouldn't be used in
that way. Favour composition over inheritance, saving inheritance for
the times when it really makes sense - which is pretty rare, IMO.
(Absolutely vital when it *does* make sense, of course.)
Yes - see the bottom paragraph of the page.
Hmm... not sure there'd be much value in that, to be honest.
That's not what that would be saying though. It would be saying "this
is a list of things which derive from ISomething". You wouldn't be able
to *add* to the list, but you'd be able to get anything out of the list
and treat it as an ISomething.
C
cody
I'd vote for functionstyle casting.
MyType b = MyType(a);
This also has the advantage that you can "override" the casting operation if
you create a method named MyType which returns MyType, others may see this
as disadvantage, however..
MyType b = MyType(a);
This also has the advantage that you can "override" the casting operation if
you create a method named MyType which returns MyType, others may see this
as disadvantage, however..
C
cody
I saw a post a long time ago by Eric Gunnerson who hinted at a
I absolutely vote for that! How could I forget this one...
I absolutely vote for that! How could I forget this one...
C
cody
7) In generics, I *think* the Java concept of '?' is useful, eg:
The question is: Is this just a syntax thing, which means that the variable
really is IList<CertainType> under the hood, but the compiler only allows
certain operations on the variable as if the type would be unknown (besides
the fact it is derived from ISomething)?
The question is: Is this just a syntax thing, which means that the variable
really is IList<CertainType> under the hood, but the compiler only allows
certain operations on the variable as if the type would be unknown (besides
the fact it is derived from ISomething)?
D
Daniel O'Connell [C# MVP]
cody said:
Ugh, thats worse than the current convention, IMHO. Its less clear what you
are doing, it potentially clashes with other things, and it looks an awful
lot like a constructor.
Yeap, that sucks, to be honest. Thats why I was arguing against combinging
the conversion and casting operator in the first place.
C
cody
The semantic problem is there is no differentiation between *casting* and
But this is a good thing, IMO. Maybe you have to refactor your code so that
some casts would be invalid now:
myEnum = (MyEnum)GetInt32();
If you change MyEnum from enum to a class or struct you just have to add a
userdefined conversion operator to that class/struct and the code would be
legal again.
If there would be a different syntax between conversion/cast you had to
change all lines from "cast GetInt32()to MyEnum" to "convert GetInt32() to
MyEnum" or something like that.
But this is a good thing, IMO. Maybe you have to refactor your code so that
some casts would be invalid now:
myEnum = (MyEnum)GetInt32();
If you change MyEnum from enum to a class or struct you just have to add a
userdefined conversion operator to that class/struct and the code would be
legal again.
If there would be a different syntax between conversion/cast you had to
change all lines from "cast GetInt32()to MyEnum" to "convert GetInt32() to
MyEnum" or something like that.
D
Daniel O'Connell [C# MVP]
cody said:
Yeap, as you should. I am not a fan of conversions in general.
T
Thomas Due
Jon said:
It might be a stupid question, but what is AOP?
--
Thomas Due
Posted with XanaNews version 1.17.5.7
"There is always some madness in love. But there is also always some
reason in madness."
-- Friedrich Nietzsche
J
Jon Skeet [C# MVP]
Thomas Due said:
Aspect Oriented Programming.
Don't have time to elaborate right now, unfortunately - hopefully
someone else will...
J
Jon Skeet [C# MVP]
cody said:
Yes, that's basically it.
F
Frans Bouma [C# MVP]
cody said:
casting is something that results in special statements in the IL, you
can't typically get the speed from type conversions at runtime through
a method. Though you can achieve this if you want to, with implicit
conversion operators.
function style casting makes the language ambiguous:
MyType b = MyTypeT(a);
MyType b = MyType(a);
which one is a method call and which one is a cast? Yeah, if you look
closely you'll see it. though:
MyType b = (MyType)a;
MyType b = MyTypeT(a);
now you see it very clearly.
Don't make C# look like VB.NET, VB.NET is very ambiguous, the least
thing we need is ambiguous statements in C#.
FB
--