Strong typing does not imply greatness and scalabilty in a program, nor does its lack imply unmanageable projects. You must earnestly meditiate on my favorite rule of programming

• Bad programers write bad programs in every language.

Class::Contract enforces type saftey the same way perl does, if the method defined in the class (or its ancestors), it calls it. Otherwise, it bombs.Consider the following example.Here is the contract object.

package FunkyNum;
use strict;
use Class::Contract;


contract {
   attr 'val';

   ctor 'new';
     impl { ${self->val} = $_[0] || 0;  }; #arn't I tricky

   method 'plusequal';
     pre   { defined $_[0] };

     impl {
       ${self->val} += $_[0];
     };
   method 'printval';
     impl {
       return ${self->val};
     }
};
[download]

use strict;
use FunkyNum;
my $x = new FunkyNum 2;
$x->plusequal(2);
print "num is " . $x->printval . "\n";
$x->plusequal(("woah", "there", "fella"));
print "num is " . $x->printval . "\n";
$x->nomethod;
[download]

num is 4
num is 4
Can't locate object method "nomethod" via package "FunkyNum" at contract.pl line 8.

pre   { ref $_[0] && $_[0]->isa("FunkyNum") };
[download]

1. Your pre and post can check all data to ensure that the implentation does what it says it will do. This works great on very strictly defined methods like datastructure algorithms.
2. encapsulated attributes
3. a chance to learn an entirely new and wierd syntax. (This should change once this gets moved to 5.6 semantics)
4. a bunch of other things that the pod page describes.

1. Performance, a lot of it. How much depends on how often you access attributes and how many pre and posts you have.
2. Any semblance of normal perl syntax.
3. Lots of time if you descide to change a contract.

Oh Monk! Learn the ways of typeless variables.
Oh Monk! Check out ML and see what a true strict typing language is capable of.
Oh Monk! Hire good coders and train the bad ones. (We are always here for you, even for hire!)

---
crulx
crulx@iaxs.net

Perhaps (probably) I don't rightly understand the question... but in my experience, the very fact that Perl is "weakly" typed has been a boon in large projects. For example, one current job I'm working on has over 500 separate small scripts (automated jobs working with various databases to perform specific functions) as well as several multi-thousand-line application "scripts," being maintained by as many as 50 people at any time. Since we don't have to worry about whether a subroutine expects a int or a long int, development has been remarkably easy.

That said, every named subroutine we have does perform checking, not upon the "type" of the data, but upon its "domain." For example:

sub member_bleh
{
 my $self = shift;
 $self->validate(); # will die() if data is invalid
 if (@_)
 {
  my $value = shift;
  if ($value < 15 or $value > 143.51)
  {
   die ("$value out of range (15 .. 143.51) in  member_bleh");
  }
  $self->{member_bleh} = $value;
 }
 return $self->{member_bleh};
}
[download]

It looks like Class::Contract could be a useful tool to perform this sort of data validation, but relying upon "types" as a validity test (at least primitive types) is a very dangerous thing. OTOH, Perl does allow you to check object references, so if you accept data in the form of an object which contains already-validated data, you do have a "strong typing" system to work with: die "not Right::Class: $ref" unless ( ref $ref && $ref->isa("Right::Class") ); is one such example...

Hope that is on task :-)