[vtk-developers] Inconsistent methods in certain classes.

Prabhu Ramachandran prabhu at aero.iitm.ernet.in
Mon Jun 3 07:57:51 EDT 2002


hi,

As promised by me during the last chat session I (and my computer)
have looked at the various VTK classes for inconsistent method names.
We looked at the classes in ['common', 'filtering', 'io', 'imaging',
'graphics', 'rendering', 'hybrid', 'patented'].  All under Linux so
none of the win32 classes were parsed.  I looked specifically for
methods that were of the form SetVariableToState.  But if I did get
anything else that looked funny I noted that too.  Here are the
results.

Of the 588 classes that were checked I found that only a few seemed to
have bad(?) errors.

Testing vtkExtractTensorComponents
vtkExtractTensorComponents might have inconsistent methods?
['ScalarIsComponent', 'ScalarIsDeterminant',
'ScalarIsEffectiveStress']

These should be SetScalarModeToComponent SetScalarModeToDeterminant
etc.

Testing vtkHyperStreamline
vtkHyperStreamline might have inconsistent methods?
['IntegrateMajorEigenvector', 'IntegrateMediumEigenvector',
'IntegrateMinorEigenvector']

This I'm not too sure about since there isnt a variable which has the
three states.  So maybe this is not a problem at all.  I haven't
looked at the code in vtkHyperStreamline.cxx to check it out.  Maybe
some expert can comment on this?


Testing vtkPolyDataConnectivityFilter
vtkPolyDataConnectivityFilter might have inconsistent methods?
['InitializeSeedList', 'InitializeSpecifiedRegionList']

This again I am not sure about the above


Testing vtkVRMLImporter
vtkVRMLImporter might have inconsistent methods?
['enterField', 'enterNode', 'exitField', 'exitNode', 'useNode']

the VTKMLImporter has the above methods which dont seem to satisfy the
standard conventions.  Comments?


All in all this is good news.  I thought there would be more
inconsistent methods but basically only one of the classes seems to be
a serious offender.

How I tested?
^^^^^^^^^^^^^

  (1) The following classes were not checked:

    (a) Classes that segfaulted on parsing (since there is no active
    pipeline) were avoided.  These include ['vtkLODProp3D',
    'vtkPropAssembly', 'vtkRayCaster' ].  

    (b) Non-instantiable classes were also obviously not checked.

  (2) Some classes caused additional problems and were checked
  manually.  ['vtkCardinalSpline', 'vtkDelaunay3D',
  'vtkGaussianSplatter', 'vtkImageMarchingCubes', 'vtkOBBTree',
  'vtkVRMLImporter'] and the any class that matched
  ['InteractorStyle', 'RenderWindowInteractor', 'Widget', 'Renderer'].

  (3) I used the vtkMethodParser to club all methods of a given class
  into BooleanVariableOn/Off, GetVariable/SetVariable, pure Get and
  SetVariableToState types.

  (4) The remaining methods did not fall into these categories.  Of
  those I eliminated about 113 standard methods like 'Update',
  'Register' etc.  

  (5) I check for all the remaining methods and see if they take no
  arguments (i.e. they are like SetVariableToState()).  If they dont I
  keep them.  The rest that do take args are removed. 

  (6) Print the results and look at the output for errors.


I'd appreciate comments on what to do.  AFAIK the only serious
offender is vtkExtractTensorComponents and of no one has objections I
can fix it sometime.

prabhu




More information about the vtk-developers mailing list