not only it distress the programmer, it distress the GC (making a new instance every time).
or why aren't they structures?
thanks.
EDIT: do you think that at least it could provide as some method such as ToBold(), that create a new instance, just in bold?
It simplifies the usage from the render system.
If the framework were to allow Font to be mutable, it would need to detect changes, and rework how it's rendering happens on a regular basis. Since Font creates a native resource, keeping this immutable prevents the system from worrying about having to recreate handles internally on a repeated basis.
Also, I disagree in terms of "Distress to the programmer". By making Font immutable, it makes it more obvious what is happening when the user creates a Font object. If you want a new Font, you need to create a new Font object, which in turn creates new native font resources. Making Font immutable makes it more clear what is happening - you're less likely to create a performance problem accidentally.
Were Font mutable, it would be less obvious that you were creating handles repeatedly as you changed your Font properties.
They aren't structures because they need to have finalizers to wrap the underlying objects and provide a sensible IDisposable implementation. What happens if you Dispose() your own copy of a struct? Do you clone the handle each time?
It isn't really much stress on the GC...
It also allows the Font to be re-used safely without worry about it changing half way through an operation ;-p
I disagree this distresses the programmer. There are plenty of immutable types in the BCL which are used on a daily basis by programmers and don't cause any issues. System.String for example.
One of the benefits of being immutable is that you don't have to create a new instance every time. You can re-use the same Font type as often as you like because it's not going to change. On the other hand, if it were mutable, you would need to make a copy every time to help guarantee that no one else changed it out from under you.
Lastly, Font is not actually an immutable class in the strictest sense of the word. It implements IDisposable and in the Dispose method tears down the underlying native object.
Well, ask yourself some questions.
First, is a font logically a mutable thing, like a grocery list, or an immutable thing, like a number? If you are modelling a grocery list in a program, it makes sense to make it mutable because you typically think of having one grocery list the contents of which change as you run out of or purchase particular items. But numbers you typically model as being immutable -- the number 12 is the number 12, now and forever.
I think of "Helvetica 12 point bold" as being a fixed, immutable thing, like a number, not something I can change.
Second, is a font logically more like a value that you can make copies of, or is it more like a single thing that you can refer to? I don't think of having "two copies" of Helvetica; I think of referring to Helvetica. Whereas numbers I think of as having different copies of for different purposes -- when I have 12 items on my grocery list and 12 keys on my keyring, I don't think of both of those things as "referring to 12".
Since I think of fonts as being immutable and referred to, rather than as mutable and copied by value, I personally would model fonts as immutable reference types. Perhaps your intuitions about fonts are different than mine.