Addressing 6.2 Changes

Nov 11, 2008 at 8:00 PM

When we originally wrapped Virtual Earth we made our own version of VEMap.LoadMap that didn't follow its JavaScript signature exactly. The JavaScript version had 7 parameters, all of which were optional, and this is uncommon in C#. So we created a method that took the 3 most common parameters and added our own structure (LoadMapOptions) to handle the other less commonly used and optional parameters.


Now in 6.2, the Virtual Earth team has done something similar for new features by adding them to a VEMapOptions class. The LoadMap method still accepts all 7 original parameters, but now you can also pass an 8th optional parameter of type VEMapOptions. VEMapOptions adds four new settings and future additions are likely to be placed there.


The question is, how do you think we should resolve this? I see three different ways:


  1. Make the C# signature match the JavaScript signature exactly and get rid of MapLoadOptions (VIEWS).
    1. - This will break existing VIEWS applications
    2. - This will go against .Net coding guidelines and may seem 'strange' to native .Net developers
    3. - Parameters cannot be optional in C# so many overrides will have to be defined
  1. Merge the MapOptions (VE) and MapLoadOptions (VIEWS) classes
    1. + This will not break existing VIEWS applications
    2. - This will not be as intuitive to maintain because the class will be a mixture of JavaScript wrapped code and code that's used only within VIEWS
    3. - This can become confusing to end users because this class won't map directly to a Virtual Earth object (whereas the rest of the code either maps or it doesn't - there is no mixing)
  1. Add a MapOptions (VE) property  to the existing MapLoadOptions (VIEWS) structure
    1. + This will not break any existing VIEWS applications
    2. + It's is easy to implement
    3. - It could be confusing having a MapLoadOptions.MapOptions property


What are your thoughts?