MSFT changing classes when they say we shouldn't

Hilton · Joined: 08 Aug 2007 Posts: 56

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

Archived from group: microsoft>public>dotnet>framework>compactframework

user · Joined: 08 Aug 2007 Posts: 286

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

"Hilton" wrote in message $Pv2.6729@newssvr23.news.prodigy.net...
>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
>
>

Simon Hart [MVP] · Joined: 03 Oct 2007 Posts: 95

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.
--
Simon Hart
Visual Developer - Device Application Development MVP
http://simonrhart.blogspot.com

"Hilton" wrote:

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

Hilton · Joined: 08 Aug 2007 Posts: 56

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

Hilton

"Simon Hart [MVP]" wrote in message @microsoft.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.
> --
> Simon Hart
> Visual Developer - Device Application Development MVP
> http://simonrhart.blogspot.com
>
>
> "Hilton" wrote:
>
>> 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
>>
>>
>>

user · Joined: 08 Aug 2007 Posts: 286

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

"Hilton" wrote in message $hI1.5546@nlpi061.nbdc.sbc.com...
>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
>
> Hilton
>
>
> "Simon Hart [MVP]" wrote in message
> @microsoft.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.
>> --
>> Simon Hart
>> Visual Developer - Device Application Development MVP
>> http://simonrhart.blogspot.com
>>
>>
>> "Hilton" wrote:
>>
>>> 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
>>>
>>>
>>>
>
>

Hilton · Joined: 08 Aug 2007 Posts: 56

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

"" wrote in message
news:%23g0dOvdaIHA.3696@TK2MSFTNGP03.phx.gbl...
> 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
>
>
>
> "Hilton" wrote in message
> $hI1.5546@nlpi061.nbdc.sbc.com...
>>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
>>
>> Hilton
>>
>>
>> "Simon Hart [MVP]" wrote in message
>> @microsoft.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.
>>> --
>>> Simon Hart
>>> Visual Developer - Device Application Development MVP
>>> http://simonrhart.blogspot.com
>>>
>>>
>>> "Hilton" wrote:
>>>
>>>> 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
>>>>
>>>>
>>>>
>>
>>
>
>

Simon Hart [MVP] · Joined: 03 Oct 2007 Posts: 95

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

"Hilton" wrote:

> 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
>
> Hilton
>
>
> "Simon Hart [MVP]" wrote in message
> @microsoft.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.
> > --
> > Simon Hart
> > Visual Developer - Device Application Development MVP
> > http://simonrhart.blogspot.com
> >
> >
> > "Hilton" wrote:
> >
> >> 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
> >>
> >>
> >>
>
>
>

Hilton · Joined: 08 Aug 2007 Posts: 56

Simon Hart [MVP] wrote:
> 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.

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

Simon Hart [MVP] · Joined: 03 Oct 2007 Posts: 95

You don't work directly with IDisposable, you call a method Dispose which is
implemented by IDisposable.
--
Simon Hart
Visual Developer - Device Application Development MVP
http://simonrhart.blogspot.com

"Hilton" wrote:

> Simon Hart [MVP] wrote:
> > 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.
>
> 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
>
>
>

Hilton · Joined: 08 Aug 2007 Posts: 56

Simon Hart [MVP] wrote:
> You don't work directly with IDisposable, you call a method Dispose which
> is
> implemented by IDisposable.

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

Hilton

Simon Hart [MVP] · Joined: 03 Oct 2007 Posts: 95

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 Hart
Visual Developer - Device Application Development MVP
http://simonrhart.blogspot.com

"Hilton" wrote:

> Simon Hart [MVP] wrote:
> > You don't work directly with IDisposable, you call a method Dispose which
> > is
> > implemented by IDisposable.
>
> IDisposable doesn't implement anything - it is an interface.
>
> Hilton
>
>
>

Hilton · Joined: 08 Aug 2007 Posts: 56

Simon Hart wrote:
>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();

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

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

Christopher Fairbairn · Joined: 08 Aug 2007 Posts: 19

Hi,

"Hilton" wrote in message $so6.2347@newssvr19.news.prodigy.net...
> 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.

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

WIN32, CIM, MSFT most info seems to be in all 3 of these... err.. namespaces? is any one of them better than the other? should i typically stick to win32 or cim or does it not matter? Justin

Where is MSFT OLE DB Provider for Oracle I am writing an .NET app with an oracle backend DB. I have been told the most efficient way of accomplishing this is by using MSFT OLE DB Provider for Oracle. I don't have it installed, or at least I can't find it anywhere. I have tried loading the MDA

To MSFT: About this nasty worm messages Hi! Isn't it possible to configure the mail server to automatically drop those nasty virus messages? I can see that you're removing the messages after some time, but couldn't this be done instantly? Just an idea. Patrick

3D Points (structs vs classes) When I have a 3-Dimensional Point is it better to use a class or a struct? I heard that if the size of the struct is greater than 16 bytes but in my feelings using a class for 3 double values (24 bytes) is overhead. In the app I've planned i would have th

CCW and method parameters being classes????? Hello, I'm having a problem with CCW and method parameters. Some of the parameters are classes. It seems that these classes (or at least the properties inside the class) are not seen from my VB client Do I have to declare an interface for these classes (e