Silverlight Controls and Silverlight Toolkit

Re: Why is the TextBlock class non inheritable (sealed)?

mgmdomingos — Sat, 04 Jul 2009 11:37:03 GMT

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?

Re: Why is the TextBlock class non inheritable (sealed)?

mgmdomingos — Sat, 04 Jul 2009 11:35:07 GMT

Can you be more specific when you speak about the binding and the converter class? Could you give an example?

Re: Why is the TextBlock class non inheritable (sealed)?

AdamWM — Tue, 30 Jun 2009 15:27:36 GMT

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.

Re: Why is the TextBlock class non inheritable (sealed)?

tanmoy.r — Tue, 30 Jun 2009 15:11:46 GMT

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.

Re: Why is the TextBlock class non inheritable (sealed)?

AdamWM — Tue, 30 Jun 2009 14:57:31 GMT

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..."

Re: Why is the TextBlock class non inheritable (sealed)?

AdamWM — Tue, 30 Jun 2009 14:55:54 GMT

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...

Re: Why is the TextBlock class non inheritable (sealed)?

tanmoy.r — Tue, 30 Jun 2009 14:44:36 GMT

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.

Re: Why is the TextBlock class non inheritable (sealed)?

mgmdomingos — Tue, 30 Jun 2009 13:29:29 GMT

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.

Re: Why is the TextBlock class non inheritable (sealed)?

yifung — Mon, 29 Jun 2009 17:50:52 GMT

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

Re: Why is the TextBlock class non inheritable (sealed)?

AdamWM — Mon, 29 Jun 2009 17:33:38 GMT

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...

Re: Why is the TextBlock class non inheritable (sealed)?

yifung — Mon, 29 Jun 2009 17:18:28 GMT

You could style a Button to look like a link. There's also a HyperlinkButton that you can probably use

Re: Why is the TextBlock class non inheritable (sealed)?

AdamWM — Mon, 29 Jun 2009 13:25:51 GMT

Well I, for one, would like to inherit from TextBlock to create a Link button that displays clickable text like an HTML link.

Re: Why is the TextBlock class non inheritable (sealed)?

yifung — Fri, 12 Jun 2009 20:34:01 GMT

Out of curiosity, what's your scenario for wanting to subclass the TextBlock?

Re: Why is the TextBlock class non inheritable (sealed)?

tanmoy.r — Fri, 12 Jun 2009 14:53:22 GMT

ctually sealed classes improves performance. So many classes you will find are sealed. You can check if you can do something with extention methods.

Why is the TextBlock class non inheritable (sealed)?

mgmdomingos — Thu, 11 Jun 2009 18:44:05 GMT

It would be very good if I could extend this class to have my own TextBlock control, so why is it sealed?