5

In the day job, I work on a VB6 (I know, but don't mock the afflicted...) application that uses a number of libraries we have written (also in the ever illustrious VB6). One of these supporting libraries had a load of private members exposed via public properties, and I was asked to remove the properties, and promote the private member variables into public fields with the same name as the original properties.

Now, I'm no COM expert, but I was under the impression that each and every exposed item on a class gets it's own GUID. Since we would be going from a situation where each value went from 2 Guids (Property Get and Property Let) to one where they only used the one (the public field), I was expecting this to break binary compatibility - but it seems it hasn't done that.

Can anyone explain why?

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
Martin Milan
  • 6,346
  • 2
  • 32
  • 44
  • 1
    more to the point, why would you want to replace the properties with public fields? – Sam Holder May 26 '10 at 15:05
  • Because I had firm instructions to do so from my technical lead... Remember what I said about not mocking the afflicted lol? I've given up looking for reason - it's a fool's crusade... – Martin Milan May 26 '10 at 15:22
  • Compile it both ways, dump the IDL of each version using OLEView, and you can directly see what has / has not changed. – StayOnTarget Jun 28 '18 at 16:03

2 Answers2

7

No, it hasn't broken compatibility because it hasn't removed the property get and property let methods. It's just that the compiler is now writing them for you.

Isn't this one of the few areas where VB6 is arguably better than .Net?

  • In .Net public fields behave differently to public properties, and this makes some refactorings difficult and causes confusion.
  • In VB6 public fields behave exactly like public properties, which is why it's possible to switch without affecting binary compatibility. Behind the scenes, the compiler generates property get and set routines for public fields. In a sense VB6 has automatically implemented properties (now advertised as a "new feature" in VB10)...
Glorfindel
  • 21,988
  • 13
  • 81
  • 109
MarkJ
  • 30,070
  • 5
  • 68
  • 111
  • Having a single feature out of two and not having the second doesn't really look like an advantage to me... – vines Mar 28 '18 at 15:32
  • Vines I don't understand your comment. Vb6 has explicit properties and public fields. What two features are you talking about? – MarkJ Mar 29 '18 at 21:11
1

I think it's a bit more subtle than that. You get a GUID for the COM interface (not each individual field/method). As I understand it the binary compatibility attempts to work out if the interface your currently compiling is backwards compatible with a reference version of your DLL (assuming you have one) and only changes the GUID if they are not compatible.

I'm therefore also surprised that it has decided removing all the get/set methods is compatible :/

Paolo
  • 22,188
  • 6
  • 42
  • 49
  • Thanks for that... I thought the GUID was held per method (been a while since I got mixed up in it - the last time was while working on some COM-Interop from VB2005 a few years back...). You're right though. Yes, I'm surprised it was found to be compatible as well... – Martin Milan May 26 '10 at 15:38
  • It is compatible because it **hasn't removed** the get/set methods. See my answer for more details. – MarkJ Oct 21 '11 at 11:44