MSFT changing classes when they say we shouldn't

  • Thread starter Thread starter Hilton
  • Start date Start date
H

Hilton

A while back I wrote about CF 1's Form not implementing IDisposable. Seems
like there are other classes that also don't; e.g. SolidBrush. Note however
that these classes CF 2 do implement IDisposable. This is, by Microsoft's
definition, a breaking change.

I just tried "using (Brush ...)" and got compilation errors...

Hilton
 
And...? Nobody is perfect. The CF 1.0 version cleaned up in the finalizer.
They realized the mistake and made it IDisposable in CF 2.0. What would you
have preferred? That they leave it non-disposable forever?

The list of companies/developers that hasn't always followed best practices
is a lot longer than just Microsoft. Can you claim you've never made a
mistake and revised your code in a later version?


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
 
How is that a breaking change? It would be different if the IDisposable
implementation was removed in later versions of the CF as your code might be
calling Dispose or using the "using" clause which would then result in it not
compiling and running.
 
But again, so what? It changed. It has no effect on existing code. It
isn't a perfect world, and if this causes heartburn then I could give a
examples of things that would require hospitalization. This example is
rather insignificant, and since none of us have a Delorean and flux
capacitor it's pretty safe to say absolutely nothing can be done about it.

Problems this causes: 0
Possibility of "fixing" it: 0
Spending our time doing something other than beating the ghost of a dead
horse: priceless

--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com
 
Chris,

I do agree with you, I was just pointing out that IDisposable was added
after CF 1 (to several classes) and that this action goes against MS's
suggestions. FWIW: I agree with you that MS did the right thing in 'fixing'
it. IMHO, it is better to 'break' something to fix it than leaving it
broken. Kinda like a nose job except in the case of Jennifer Grey.

Hilton
 
Technically Microsoft is right in saying the semantics of a class change when
implementing a new interface but with IDisposable this will not "break"
anything because generally you never work directly with the IDisposable
interface do you.
--
Simon Hart
Visual Developer - Device Application Development MVP
http://simonrhart.blogspot.com
 
Simon said:
Technically Microsoft is right in saying the semantics of a class change
when
implementing a new interface but with IDisposable this will not "break"
anything because generally you never work directly with the IDisposable
interface do you.
Click to expand...

I agree with your first part, but sure you work directly with IDisposable -
C# forces you to call Dispose() to clean up (I once proposed a 'fix' for
this, but was shot down by the 'purists' in this NG) NOTE: I put quotes
around the words that I use is the loosest sense - there is my disclaimer -
no flames please.

Anyway, you must call Dispose and it also changes the way you write code;
e.g. "using (Brush brush = new SolidBrush (...))" doesn't even compile.

And just to be clear, I'm glad MS realized their mistake and fixed it.

Hilton
 
You don't work directly with IDisposable, you call a method Dispose which is
implemented by IDisposable.
 
Simon said:
You don't work directly with IDisposable, you call a method Dispose which
is
implemented by IDisposable.
Click to expand...

IDisposable doesn't implement anything - it is an interface.

Hilton
 
I think we are going round in circles here. When I say "you call a method
Dispose which is implemented by IDisposable" meaning a class must implement
the Dispose method when implementing the IDisposable interface.

Which goes back to my original response "you don't work directly with the
IDisposable interface". You don't for example do this:

IDisposable myForm = new MyForm();
myForm.Dispose();

Your original argument is therefore completely nonsense. Microsoft's change
doesnt cause any code to break, so therefore it is not a "breaking change".
 
Simon said:
I think we are going round in circles here. When I say "you call a method
Dispose which is implemented by IDisposable" meaning a class must
implement
the Dispose method when implementing the IDisposable interface.

Which goes back to my original response "you don't work directly with the
IDisposable interface". You don't for example do this:

IDisposable myForm = new MyForm();
myForm.Dispose();
Click to expand...

When I do a "using ()", I'm working directly with the IDisposable interface,
that's why I cannot do it on CF 1. The "using()" is just syntactic candy
for try-finally in which the compiler creates a "((IDisposable)
obj).Dispose()". That is very much "working directly with IDisposable".

Your original argument is therefore completely nonsense. Microsoft's
change
doesnt cause any code to break, so therefore it is not a "breaking
change".
Click to expand...

The original argument that you assign to me (and that you say is nonsense)
was "This is, by Microsoft's definition, a breaking change." My claim is
that MICROSOFT says that it is a breaking change, not me, Microsoft - go
back and re-read all my posts in this thread - I always attribute the
"breaking change" to Microsoft. I even quoted MS with a URL and everything.
Here it is again:

---
I agree with both you and Chris. However, Microsoft explicityly state: "It
is a version breaking change to add the IDisposable interface to an existing
class, as it changes the semantics of the class."

http://msdn2.microsoft.com/en-us/library/system.idisposable(VS.71).aspx
---

Anyway, I don't want to get into a pissing match here, I was just pointing
out the fact that IDisposable was added after CF 1 to several classes by
Microsoft and that it was something that MS said we shouldn't do. I also
pointed out that I agree with MS's adding IDisposable after realizing their
mistake.

Have a great weekend,

Hilton
 
Hi,

Hilton said:
The original argument that you assign to me (and that you say is nonsense)
was "This is, by Microsoft's definition, a breaking change." My claim is
that MICROSOFT says that it is a breaking change, not me, Microsoft - go
back and re-read all my posts in this thread - I always attribute the
"breaking change" to Microsoft. I even quoted MS with a URL and
everything.
Click to expand...

The full statement within MSDN is as follows:

"It is a version breaking change to add the IDisposable interface to an
existing class, as it changes the semantics of the class."

My interpretation of this is that it doesn't say you shouldn't do it, only
that before doing it you should consider the possible impact/changes it will
cause on clients of your class.

This particular example was a change between version 1 and version 2 of the
..NET CF (so was part of a version change), but it doesn't really have too
much of an impact on end user code. I assume Microsoft considered the
possible impacts of this change when they implemented it and considered it
minimal.

Code originally designed for .NET CF 1.0 will still compile without
alterations and run without error if you place it in a .NET CF 2.0 project.
Obviously it will not call Dispose(). Instead you'll just get the old
behaviour where the objects hang around for a little while longer and are
tidied up within the object's finalizer.

Obviously you can't place a using statement for these objects within a .NET
CF 1.0 application, but you shouldn't expect to be able to use features of a
later version of a runtime, base class library or language while targeting
an older version. In general Microsoft (and most other companies) develop
things with backwards compatibility in mind and not forwards compatability
(i.e. the possibility to use new features in an older environments).

This "breaking change" means that newer applications that are aware that
these objects implement IDisposable can free up resources quicker in a
standardised and well understood manor, while not breaking older
applications that are not aware (or have not been updated). Any application
which doesn't take advantage of these objects implementing IDisposable will
free the resources when the garbage collector kicks in to finalize the
objects, so no resources are leaked etc.

Hope this helps,
Christopher Fairbairn
 
Back
Top