"DO NOT seal classes without having a good reason to do so.
Sealing a class because you cannot think of an extensibility scenario is not a good reason. Framework users like to inherit from classes for various nonobvious reasons, like adding convenience members"
Couldn't have said it better myself. You guys are doing exactly the opposite of what Microsoft's own guidelines say should be done. This is exactly what I said in my response long ago - you shouldn't be erring on the side of sealing but precisely the opposite.
I really hope you guys do the right thing in the next release.
Another vote for unsealing. We want to be able to project the points on a polygon via a projection. So we can display polygons on a map with a projection. Currently have to wrap Polygon and expose all its Properties. Inheriting would be much easier
as we get the properties automatically.
I am using the SilverLight Bing maps control. I need to create a MapCircleByRadius class. I want to just inherit the Ellipse, but am going to be forced to wrap the Ellipse in a class instead. So, like MikeRussell said, I will either need to expose a bunch
of its properties or expose the Ellipse itself. Bummed. There was another time I wanted to inherit the Rectangle class too but don't remember why. Bottom line though, I'm sure I'm going to come across many cases where I would like to inherit these shapes.
Now you guys can save me a lot of time by created a good MapMarker and MapCircle class. You probably will right after I'm finished with mine, lol. Anyhow, I'm really liking SilverLight and the map control. Good job. Hope to see more features in the near
future. How about a good print from SilverLight utility!!!
In my scenario, it would be the best to extend the ScrollBar and/or ScrollViewer classes with some properties, but... what do you think ??? Both are sealed !!!! ;-(
And with the final release of Silverlight 3 (downloaded today), they remain sealed !!! ;-(
I want to create a card class (as in a playing card). I really don't want to rewrite everything required to draw the card on the screen. It would be great to be able to extend say the Rectangle or, even better, the Image class. This way .Net can draw the
card for me and all I have to do is add a few properties I want to store and methods that takes additional actions or call existing image methods just with more friendly names. Maybe a FaceValue and Suit property. I really don't need to override anything in
the Image (or Rectangle) class.
I want to create a card class (as in a playing card).
Between templates and databinding, I probably wouldn't implement a card like this. That's really tying the implementation of your card to a UI object which seems, well, wrong. For example, you could have a simple card class that exposes an int Index property,
i.e., 43 is the ace of spades. Then an instance of an Image would bind its source property to the card's Index property, and through a value converter, set the right image url. Certainly would keep your data much more cleanly separated from the presentation.
I'm a bit agnostic on the sealed vs not-sealed argument, perhaps because I haven't run into an issue that's tripped me up significantly. But for something like this, in the Silverlight/WPF/XAML/Databinding/Template world, there's really no reason to extend
an image.
darrellp
Member
4 Points
4 Posts
Re: Why are shapes sealed?
May 07, 2009 02:25 AM | LINK
From the "Framework Design Guidelines":
"DO NOT seal classes without having a good reason to do so.
Sealing a class because you cannot think of an extensibility scenario is not a good reason. Framework users like to inherit from classes for various nonobvious reasons, like adding convenience members"
Couldn't have said it better myself. You guys are doing exactly the opposite of what Microsoft's own guidelines say should be done. This is exactly what I said in my response long ago - you shouldn't be erring on the side of sealing but precisely the opposite. I really hope you guys do the right thing in the next release.
esh
Member
26 Points
30 Posts
Re: Why are shapes sealed?
May 23, 2009 08:39 PM | LINK
mikerussellnz
Member
10 Points
30 Posts
Re: Why are shapes sealed?
May 27, 2009 11:32 PM | LINK
Another vote for unsealing. We want to be able to project the points on a polygon via a projection. So we can display polygons on a map with a projection. Currently have to wrap Polygon and expose all its Properties. Inheriting would be much easier as we get the properties automatically.
jeffskvorc
Member
2 Points
1 Post
Re: Why are shapes sealed?
Jul 10, 2009 01:56 AM | LINK
I am using the SilverLight Bing maps control. I need to create a MapCircleByRadius class. I want to just inherit the Ellipse, but am going to be forced to wrap the Ellipse in a class instead. So, like MikeRussell said, I will either need to expose a bunch of its properties or expose the Ellipse itself. Bummed. There was another time I wanted to inherit the Rectangle class too but don't remember why. Bottom line though, I'm sure I'm going to come across many cases where I would like to inherit these shapes.
Now you guys can save me a lot of time by created a good MapMarker and MapCircle class. You probably will right after I'm finished with mine, lol. Anyhow, I'm really liking SilverLight and the map control. Good job. Hope to see more features in the near future. How about a good print from SilverLight utility!!!
step-et
Member
2 Points
12 Posts
Re: Re: Why are shapes sealed?
Jul 13, 2009 02:20 PM | LINK
And again one more vote AGAINST sealed classes.
In my scenario, it would be the best to extend the ScrollBar and/or ScrollViewer classes with some properties, but... what do you think ??? Both are sealed !!!! ;-(
And with the final release of Silverlight 3 (downloaded today), they remain sealed !!! ;-(
ChristianRup...
Member
8 Points
20 Posts
Re: Re: Re: Why are shapes sealed?
Oct 05, 2009 09:42 PM | LINK
Also, one vote for UNSEALED classes...
Btw. classes like "Border" would be really nice to extend a little bit (Nicer contructors, default values...)
Some of the original posts are refering to SL 1.1
Are there some updates on this issue, regarding future plans?
slyi
Participant
1027 Points
313 Posts
Re: Re: Re: Why are shapes sealed?
Dec 10, 2009 01:13 PM | LINK
in case it was missed http://blogs.msdn.com/nickkramer/archive/2009/12/03/subclassing-shape-or-more-accurately-path.aspx
cwood
Member
2 Points
1 Post
Re: Why are shapes sealed?
Apr 02, 2011 08:09 AM | LINK
Here's a scenario:
I want to create a card class (as in a playing card). I really don't want to rewrite everything required to draw the card on the screen. It would be great to be able to extend say the Rectangle or, even better, the Image class. This way .Net can draw the card for me and all I have to do is add a few properties I want to store and methods that takes additional actions or call existing image methods just with more friendly names. Maybe a FaceValue and Suit property. I really don't need to override anything in the Image (or Rectangle) class.
The alternative is just stupid:
class Card {
public Image CardImage = new Image();
// add my other properties and methods here.
}
jackbond
Contributor
5812 Points
1559 Posts
Re: Why are shapes sealed?
Apr 02, 2011 08:43 AM | LINK
Between templates and databinding, I probably wouldn't implement a card like this. That's really tying the implementation of your card to a UI object which seems, well, wrong. For example, you could have a simple card class that exposes an int Index property, i.e., 43 is the ace of spades. Then an instance of an Image would bind its source property to the card's Index property, and through a value converter, set the right image url. Certainly would keep your data much more cleanly separated from the presentation. I'm a bit agnostic on the sealed vs not-sealed argument, perhaps because I haven't run into an issue that's tripped me up significantly. But for something like this, in the Silverlight/WPF/XAML/Databinding/Template world, there's really no reason to extend an image.
Khet - The first Silverlight multiplayer game
Zork I: The Great Underground Empire