[mapguide-trac] #123: Cannot find overload for MgMappingService::GeneratePlot()

[MapGuide Open Source]

#123: Cannot find overload for MgMappingService::GeneratePlot()
----------------------------+-----------------------------------------------
 Reporter:  waltweltonlair  |         Owner:        
     Type:  defect          |        Status:  new   
 Priority:  high            |     Milestone:  1.2   
Component:  Web API         |       Version:  1.2.0 
 Severity:  major           |    Resolution:        
 Keywords:                  |   External_id:  929288
----------------------------+-----------------------------------------------
Comment (by waltweltonlair):

 The !GeneratePlot call for which the problem occurs takes, as its second
 argument, an !MgCoordinate object.  !MgCoordinate is a base class from
 which other classes like MgCoordinateXY or MgCoordinateXYM derive.  In
 this case we're passing in an MgCoordinateXY object.

 Because !GeneratePlot has multiple overloads, the SWIG generated PHP code
 needs to check the class type of this parameter to determine which
 overload to call.  It's doing this by comparing the class type name of the
 passed-in object to the class type name declared in the overload.  In our
 case the class type name for the pass-in object is "MgCoordinateXY", and
 the class type name declared in the overload is "!MgCoordinate".  The
 comparison is a string equality check, and therefore it fails.  So SWIG
 ends up failing to correctly identify that the passed-in parameters match
 one of the !GeneratePlot overloads.

 Somehow the autogenerated SWIG code needs to be made smarter - it needs to
 take into account object inheritance when it does the checks.  Maybe this
 is a supported feature of SWIG, and we need to figure out how to turn it
 on.  It could also be a limitation of SWIG, and that would be bad, since I
 bet there are many methods in our API for which a similar problem would
 arise.

 Note that the information to do the correct checks is there.  SWIG obtains
 a !ClsInfo object for the parameter, and this includes its inheritance
 structure.  So it's possible to check the function type not only against
 the parameter's most derived type (like it currently does), but also
 against its parent types.  It could simply start at the most derived type
 and keep checking until it finds a match or runs out of parent types (in
 which case the parameter type doesn't match the function type).

-- 
Ticket URL: <https://trac.osgeo.org/mapguide/ticket/123#comment:1>
MapGuide Open Source <http://mapguide.osgeo.org/>
MapGuide Open Source Internals