Weak Type Issues

In weakly typed languages like Perl and Python, it is hard or impossible for an outside application (like FIT) to determine at runtime, how two (primitive) objects should be compared.

DaveThomas gave the following example:

Plusser
a b plus()  
1 2 4 or should it be 4.0?
x y xy concatenation vs addition

I resolved this in my AlternatePerlImplementation by altering the way fit works in general. Here is my take:

  • In this case Plusser is class (subclass of ColumnFixture)
  • a(), b() plus() are all methods of Plusser
  • a and b are no different from plus in how they are called
  • Each method has complete control of how it is interpreted
  • The methods have no return values

This varies slightly from Ward's take:
  • Some headers are attributes, some methods
  • The return values of the methods determine test success

So in this example the a and b methods will (probably) put their values into attributes. And the plus method will determine (in any way it sees fit) how to plus the two attributes, and determine whether the test cell passes, fails, is excepted or is ignored.

This seems like too much work to do in a fixture class (and it is), but at least the typing issues aren't a problem. The good news is that most of the work can be delegated back to the super class.

See PerlTypeIssues for an example of how I solve this example in Perl.

-- BrianIngerson

See DynamicTypeIssues for an overview of other issues involving the port of FIT to dynamically typed programming languages.

 
Last edited October 22, 2005
Return to WelcomeVisitors