Skip to main content
Home Forums Silverlight Programming Silverlight Controls and Silverlight Toolkit Why is the TextBlock class non inheritable (sealed)?
14 replies. Latest Post by mgmdomingos on July 4, 2009.
(0)
mgmdomingos
Member
18 points
20 Posts
06-11-2009 2:44 PM |
It would be very good if I could extend this class to have my own TextBlock control, so why is it sealed?
tanmoy.r
Contributor
3580 points
708 Posts
06-12-2009 10:53 AM |
ctually sealed classes improves performance. So many classes you will find are sealed. You can check if you can do something with extention methods.
yifung
3257 points
537 Posts
06-12-2009 4:34 PM |
Out of curiosity, what's your scenario for wanting to subclass the TextBlock?
AdamWM
12 points
11 Posts
06-29-2009 9:25 AM |
Well I, for one, would like to inherit from TextBlock to create a Link button that displays clickable text like an HTML link.
06-29-2009 1:18 PM |
You could style a Button to look like a link. There's also a HyperlinkButton that you can probably use
06-29-2009 1:33 PM |
yifung:You could style a Button to look like a link. There's also a HyperlinkButton that you can probably use
The HyperlinkButton would be easier to style, and I didn't know about its existence.
However, I still don't think all these controls should be sealed. I searched all the forums and you guys still haven't given any good reason to seal them. One guy mentioned performance, but how big is the gain, really? What percentage of a speed increase and/or memory decrease does sealing the classes provide? Computers are increasing in speed and memory capacity at an exponential rate, but the speed of human developers is not. Clearly it makes sense to optimize for ease of development unless the performance difference is really substantial, which I really doubt it is...
06-29-2009 1:50 PM |
One of the reasons is the extra test cost involved which is pretty significant, and Silverlight tends to be on a tight schedule. For schedule purposes the items with compelling scenarios tend to be the ones that make it. It sounds like using/styling the HyperlinkButton will work for your scenario
06-30-2009 9:29 AM |
Me for example wanted to do a TextBlock that automatically add ellipsis to text when the text exceeds the width of the textblock.
My solution was to create a new control from composition fo the textblock but in that way I didn't inherith all the properties and behaviours of the textblock, which was pretty bad.
So Microsoft is stopping good work from beeing made with the excuse of performance? I just say it's ridiculous in this case, or else I ask why aren't all the other controls sealed like the textblock if they could have better performance?? In my opinion it's just a ridiculous excuse.
06-30-2009 10:44 AM |
Hi,
Whether any class (Specially library class) should be sealed is a long debate between developers and framework developers. So what you are saying is not wrong but from the other point even a slight performance benifit might come in handy when you have lots of TextBlocks in your application.
So basically you need situations where without inheritance it "can not be/ very hard" to achive.
mgmdomingos: Me for example wanted to do a TextBlock that automatically add ellipsis to text when the text exceeds the width of the textblock.
I guess this can also be achived with using binding and onverter class.
06-30-2009 10:55 AM |
tanmoy.r:Whether any class (Specially library class) should be sealed is a long debate between developers and framework developers. So what you are saying is not wrong but from the other point even a slight performance benifit might come in handy when you have lots of TextBlocks in your application. So basically you need situations where without inheritance it "can not be/ very hard" to achive.
No, it's ridiculous to say that you should only optimize for humans' sake when their jobs would otherwise be very hard or impossible. Because computer speed is increasing exponentially but human capabilities remain constant, you should always optimize for developer productivity unless you have hard numbers that show substantial performance benefits that can't be obtained any other way.
The only reasonable excuse I've heard is that the cost of testing that their controls will behave correctly when inherited from is too high, but even then it's hardly satisfying...
06-30-2009 10:57 AM |
Just imagine if the System.Windows.Forms team said "Sorry, you can't inherit from our controls because we didn't want to take the time to test them..."
06-30-2009 11:11 AM |
AdamWM:computer speed is increasing exponentially but human capabilities remain constant, you should always optimize for developer productivity
This is true for server side where you can improve Hardware cheaply than to invest of developers time. But it is not exactly the case where you have to support millions of clients (where the code runs at client side). Because though HW are becoming cheaper and faster many people still dont upgrade them very often. for example you see this post. Its about SW upgradation. HW upgradation is still slower.
06-30-2009 11:27 AM |
tanmoy.r:This is true for server side where you can improve Hardware cheaply than to invest of developers time. But it is not exactly the case where you have to support millions of clients (where the code runs at client side). Because though HW are becoming cheaper and faster many people still dont upgrade them very often. for example you see this post. Its about SW upgradation. HW upgradation is still slower.
I'm not saying that you shouldn't care about performance -- you should. But you shouldn't try to increase performance at the expense of human productivity unless you have a very compelling reason, like actual measurement data that shows a substantial performance problem which can't be alleviated another way.
Anyway, I don't think the controls are really sealed for performance reasons. (Or if they are, they're probably poorly designed.) I think the lack of resources for testing/development may be their primary concern, but then it becomes a matter of what they want to spend their time on.
07-04-2009 7:35 AM |
Can you be more specific when you speak about the binding and the converter class? Could you give an example?
07-04-2009 7:37 AM |
tanmoy.r: Hi, Whether any class (Specially library class) should be sealed is a long debate between developers and framework developers. So what you are saying is not wrong but from the other point even a slight performance benifit might come in handy when you have lots of TextBlocks in your application. So basically you need situations where without inheritance it "can not be/ very hard" to achive. mgmdomingos: Me for example wanted to do a TextBlock that automatically add ellipsis to text when the text exceeds the width of the textblock. I guess this can also be achived with using binding and onverter class.
Could you be more specific when you speak about binding and converter class? Could you give an example?
Why is the TextBlock class non inheritable (sealed)?