[Offtopic] What would you like to change in C# and .NET?

  • Thread starter Thread starter Tom
  • Start date Start date
Tom said:
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.
Click to expand...

I'd like to see an addition to the generics which are coming soon:
operator specifications in the restriction clause of the type
specification.

This is the MAJOR flaw in generics at the moment and I can't
understand why it isn't implemented in .NET 2.0. You can't solve it
with an interface because operators are defined as static.

So a generic method which adds two elments:

public T Add(T a, T b)
{
return a + b;
}

won't work, as the compiler doesn't know if T supports +. It would be
great if something like:

public T Add(T a, T b) where T : operator +
{
return a + b;
}

would be possible. And it's a missed chance this isn't possible with
..NET 2.0 generics, especially when you know a generic type at runtime
is just a block of IL generated for you, e.g. it perfectly would have
been possible to do this.

FB


--
 
Jon said:
Aspect Oriented Programming.

Don't have time to elaborate right now, unfortunately - hopefully
someone else will...
Click to expand...

nO need, I googled a bit on "Aspect Oriented Programming". So I am
pretty clear on what it means.

I actually found an article which seems interesting:
http://www.c-sharpcorner.com/Code/2002/Nov/aop.asp

It is a bit old, but for a complete and utter newbie on the subject, it
seems pretty good to me.

--
Thomas Due
Posted with XanaNews version 1.17.5.7

"Digressions, objections, delight in mockery, carefree mistrust are
signs of health; everything unconditional belongs in pathology."
-- Friedrich Nietzsche
 
For C# - Maybe I missed something, but I supposed that using polymorphism
this is no magic and perferctly legal:

class Parent {}
class Child:Parent {}
.....
IList<Parent> myList;
.....
Child myChild = new Child();
....
myList.Add( myChild )

Am I wrong ? I think that for inserting it is even not necessary to cast
myChild as Parent ! When extrating - of course - you have to know what rabbit
you have got - it's strong-typing...

Same for interfaces, isn't it ?

Pazu
 
2) A way of declaring a variable as being private to a property

There's a very simple alternative solution: allow handling "bodyless"
properties inside the declaring class as a field. This is, by the way, how
event declarations are already handled in C#.
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...
Click to expand...

Of course. Take a look at freyalang.blogspot.com for a language taking this
approach.

Ian
 
Pazu said:
For C# - Maybe I missed something, but I supposed that using polymorphism
this is no magic and perferctly legal:

class Parent {}
class Child:Parent {}
....
IList<Parent> myList;
....
Child myChild = new Child();
...
myList.Add( myChild )

Am I wrong ? I think that for inserting it is even not necessary to cast
myChild as Parent ! When extrating - of course - you have to know what rabbit
you have got - it's strong-typing...

Same for interfaces, isn't it ?
Click to expand...

That's legal, but I can't declare that a method takes a "list of
anything" or "a list of anything deriving from Foo" as a parameter.

Note that IList<Child> *doesn't* derive from IList<Parent> - so if I
declared that the method should take IList<Parent> as a parameter, I
wouldn't be able to pass in something which was actually IList<Child>.
 
Note that IList<Child> *doesn't* derive from IList<Parent> - so if I

The right word wouldn't be "derive from" but "is assignment compatible" but,
of course, IList<Child> is not assignment compatible.

However, it seems that this is supported by the CLR. The problem with
allowing it is that you could do this:

IList<Child> childList = new IList<Child();
IList<Parent> parentList = childList; // Currently not supported
parentList.Add(new Parent()); // Bang!

Actually, this kind of extended polymorphism is already allowed for array
types (because Java supports it), and it means that every item assignment for
arrays must check the type of the item being assigned. Extending the rule to
every possible generic type would imply a similar (expensive) check.

The alternative: to perform some static "system type check", as in Eiffel.
But I'm afraid it would forbid some dynamic operations like assembly loading
at runtime. Adding a new type to an already verified class system could
potentially break the soundness of the system.

Ian
 
ianm said:
The right word wouldn't be "derive from" but "is assignment compatible" but,
of course, IList<Child> is not assignment compatible.

However, it seems that this is supported by the CLR. The problem with
allowing it is that you could do this:

IList<Child> childList = new IList<Child();
IList<Parent> parentList = childList; // Currently not supported
parentList.Add(new Parent()); // Bang!

Actually, this kind of extended polymorphism is already allowed for array
types (because Java supports it), and it means that every item assignment for
arrays must check the type of the item being assigned. Extending the rule to
every possible generic type would imply a similar (expensive) check.

The alternative: to perform some static "system type check", as in Eiffel.
But I'm afraid it would forbid some dynamic operations like assembly loading
at runtime. Adding a new type to an already verified class system could
potentially break the soundness of the system.
Click to expand...

I wasn't suggesting making the above valid though. I was suggesting the
kind of thing Java has, where you can have:

IList<? extends Parent> parentList = childList;

You can't *add* a parent to the list at that point, but you can take
something out of it and know in a type-safe way that it's assignment-
compatible with Parent.
 
ianm said:
The right word wouldn't be "derive from" but "is assignment
compatible" but, of course, IList<Child> is not assignment compatible.

However, it seems that this is supported by the CLR. The problem with
allowing it is that you could do this:

IList<Child> childList = new IList<Child();
IList<Parent> parentList = childList; // Currently not supported
parentList.Add(new Parent()); // Bang!
Click to expand...

At first I thought, why on earth isn't this possible, but then I
realized that you then also could do:
parentList.Add(new OtherChild());
which would break teh childList's typeness.

This kind of code will cause a lot of headaches among developers, I'm
sure :) ("Why isn't it possible!!")

I do agree with Jon though, it should be possible to specify that the
type passed in contains types which are compatible with a given type.

Frans

--
 
Jon said:
That's legal, but I can't declare that a method takes a "list of
anything" or "a list of anything deriving from Foo" as a parameter.

Note that IList<Child> *doesn't* derive from IList<Parent> - so if I
declared that the method should take IList<Parent> as a parameter, I
wouldn't be able to pass in something which was actually IList<Child>.
Click to expand...
I create a template wrap class to make IList<Child> as IList<Parent>. I know
its not a good solution, but this is the only way I can found.

public class AsParentList<Child, Parent> : IList<Parent> where Child: Parent
{
readonly IList<Child> mChildList;
public AsParentList(IList<Child> childList) { ... }

public Parent this[int index]
{
get { return mChildList[index]; }
set { mChildList[index] = value; }
}

// other IList memebers
}

Alright, you can create List<Parent>, and add all the item in List<Child> to
it. But I think AsParentList<> maybe would save an array object in
List<Parent>, also remove the need for init the array object.
 
My list is rather short. Most of "My Favorite Things" (functional style
programming constructs) will be there in C# 3.0. so..

- Design by contract. Can any other language feature be as important as this
one? Preferrably for the interfaces too, not just for classes.

- Java-style enumerations, where enumerations are objects, I completely
agree this is useful and aesthetic. I don't think there is any performance
issue involved, just make the switch statements compatible.

- the var keyword in C# 2.0... is it too late? I mean, the IDE can infer
types, why won't the language? The principle advantage of the introduction of
generics was not cast elimination, but type inference. This is not just about
less keystrokes, it's about quick code changes too! Besides, when C# 3.0
arrives, the keyword will be available anyway, so MS has nothing against it.
Why not now?
 
<"=?Utf-8?B?SW1hbSBUYXNoZGlkIHVsIEFsYW0=?=" <Imam Tashdid ul
My list is rather short. Most of "My Favorite Things" (functional style
programming constructs) will be there in C# 3.0. so..

- Design by contract. Can any other language feature be as important as this
one? Preferrably for the interfaces too, not just for classes.
Click to expand...

Yup :)
- Java-style enumerations, where enumerations are objects, I completely
agree this is useful and aesthetic. I don't think there is any performance
issue involved, just make the switch statements compatible.
Click to expand...

Again, yup.
- the var keyword in C# 2.0... is it too late? I mean, the IDE can infer
types, why won't the language? The principle advantage of the introduction of
generics was not cast elimination, but type inference. This is not just about
less keystrokes, it's about quick code changes too! Besides, when C# 3.0
arrives, the keyword will be available anyway, so MS has nothing against it.
Why not now?
Click to expand...

The reason var is needed in C# 3.0 is because of anonymous types. It
allows you to have variables where the type is known, but can't be
specified in the source because only the compiler knows the type.

Personally, that's the only situation I think it's nice to use it in -
I don't care about typing time nearly as much as reading time, and I
like to keep the type with the declaration.
 
Back
Top