Itai Bar-Haim - All Comments

re: Help Needed

rmsphd — Fri, 28 Sep 2007 11:29:08 GMT

i help you, but i don't understand much better who Class Diagram Work with Graphics,,, if you can help me a understand, i help you :D

Please,

and my english is poor

i am from Brasil

Sharp Develop An Open Source IDE for .NET

Imesh Gunaratne's Web Log — Mon, 06 Aug 2007 12:21:13 GMT

Sharp Develop is a FREE Open Source IDE for developing .NET Applications. This seems to be a great news

re: Generics... why so incomplete?

DavidSrbecky — Thu, 22 Feb 2007 20:11:07 GMT

Yes, rest assured that this behavior is not 'incompleteness'. It is very well thought out and if something is not possible, it is usually for very good reason.

re: Generics... why so incomplete?

Blue Ninja — Mon, 19 Feb 2007 20:19:57 GMT

Well, no wonder it's making so many people pull their hair out, then! I can see how this would in many cases cause more confusion and frustration than it would be handy. I'll have to wrap my brain around it a bit more...

re: Generics... why so incomplete?

itaibh — Mon, 19 Feb 2007 18:07:23 GMT

No, David is correct in his examples. It doesn't matter which type is exposed by reference, what really matters is the actual type behind it.

However, this should still be possible with immutable object, such as read-only lists.

Something like

List<Circle> c = new List<Circle>();

ReadOnlyList<Shape> s = c.AsReadOnly();

should have worked fine if it was possible to mark specific types as immutable (or if the CLR could identify that the types does not expose any method or property or field in such way it is changeable by regular code (not dealing with special cases like reflection based changes of private members, etc...)

Itai.

re: Generics... why so incomplete?

Blue Ninja — Mon, 19 Feb 2007 14:53:01 GMT

David,

In your first case, you are adding a rectangle to the list of shapes, not the list of circles. As long as circle and rectangle inherit from shape, that would be okay - but, you could not add the rectangle to a list of circles, because rectangles don't inherit from circles, but rather from shapes. Or am I misunderstanding that?

If I didn't misunderstand, wouldn't that change case 2 so that it would in fact not be possible to put a rectangle into a circleHandler?

re: Generics... why so incomplete?

DavidSrbecky — Sun, 18 Feb 2007 22:26:02 GMT

Not even looking at the articles I will try to give quick counter-examples:

Case 1:

List<Circle> c = new List<Circle>();

List<Shape> s = c; // Must not work because then you could...

s.Add(new Rectangle()); // ...add rectangle to circle list

Case 2:

class ShapesHandler<T> where T : Shape

{

T foo(params T[] shapes) {

return shapes[0];

}

void bar ()

{

ShapesHandler<Circle> circleHandler = new ShapesHandler<Circle>();

Circle circle = circleHandler.foo (new Shape[] {new Rectangle()}); // Assign an Rectangle to Circle... ops

}

re: Class Diagram Status

Blue Ninja — Fri, 16 Feb 2007 14:01:59 GMT

Thanks for the clarification - I'll keep checking there for updates.

re: Generics... why so incomplete?

MattWard — Fri, 16 Feb 2007 13:34:36 GMT

The following O'Reilly article discusses this, but it does not really give you a concrete reason why but instead gives you an example where such a substitution does not make sense and then shows you to solve the problem using generic methods.

http://www.ondotnet.com/pub/a/dotnet/2005/06/20/generics.html

You can get your code to compile if you use generic methods as shown below:

void foo<T>(IEnumerable<T> shapes) where T : Shape

{

}

void bar ()

{

foo (new List<Circle>());

}

class ShapesHandler<T> where T : Shape

{

void foo<K>(params K[] shapes) where K : Shape

{

}

void bar ()

{

List<Shape> someShapes = new List<Shape>();

foo (someShapes.ToArray());

}

The ShapesHandler code above needs a little more explanation since it is not really covered in the original article. At first glance your original definition would seem correct. However the original code only works if it outside of the ShapesHandler class, presumably because the type specific version needs to be created first. Inside the class itself you could probably use the type T instead of the concrete Shape class, something like:

void bar ()

{

List<T> someShapes = new List<T>();

foo (someShapes.ToArray());

}

However all the above code does not explain the "why" just the "how". The "why" is explained in the Rick Byers post linked to in the previous comment.

re: Generics... why so incomplete?

chrisstefano — Fri, 16 Feb 2007 13:15:53 GMT

There are a number of blogs on this subject. I believe the term to use is covariance.

Checkout this blog on the subject http://blogs.msdn.com/rmbyers/archive/2005/02/16/375079.aspx

re: Class Diagram Status

itaibh — Fri, 16 Feb 2007 11:05:33 GMT

Just to clear things out about the backporting comment, what I meant is that the class diagram addin will be available as a third-party addin, and WILL NOT BE INCLUDED in future 2.x releases.

The addin will be available from the addin page on sourceforge: http://sdclassdiagram.sf.net

Itai.

re: Class Diagram Status

itaibh — Sat, 10 Feb 2007 08:39:06 GMT

Yes, it will. But first I want it to get more functional. This will take some time.

In the meanwhile, you can download one of the much earlier versions from http://sdclassdiagram.sf.net

Itai.

re: Class Diagram Status

Blue Ninja — Fri, 09 Feb 2007 23:59:35 GMT

Will this be back-ported to the 2.1 branch?

re: Class Diagram Status

ChristophWille — Fri, 09 Feb 2007 08:37:30 GMT

The Montferrer bits (WPF, WF and Class Designer) can be found on our build server http://build.sharpdevelop.net/buildartefacts/

re: Class Diagram Status

darkcloud — Fri, 09 Feb 2007 07:12:15 GMT

Where to get your addin from? i want to try and use it