Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Class::Struct, Class::Contract and type Safety

by chorg (Monk)
on Feb 14, 2001 at 19:23 UTC ( #58356=perlquestion: print w/replies, xml ) Need Help??

chorg has asked for the wisdom of the Perl Monks concerning the following question:

Morning all Monks:)

I have a question about enforcing type safety in Perl. We all know that Perl is a weakly typed language, with all that implies for larger projects. I was reading about Class::Struct, and Class::Contract. I am unsure about a keypoint: Do these modules enforce type safety, and thus if I were to start a "large" project, with many people, that Perl would still be a viable choice? I am still digesting "Design by Contract" that is enforced by Class::Contract, but I was still wondering...
"Intelligence is a tool used achieve goals, however goals are not always chosen wisely..."

  • Comment on Class::Struct, Class::Contract and type Safety

Replies are listed 'Best First'.
Re: Class::Struct, Class::Contract and type Safety
by Crulx (Monk) on Feb 14, 2001 at 21:17 UTC
    Oh Monk! Mornings are always good to Perl Monks for their natural enlightened state grants them eternal bliss.

    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.
    Strong typing does not turn bad programers into good ones any more than using OO techniques does. That being said, M-J. Dominus has written a very good article explaining why typing doesnt have to suck.
    But it isn't very perl like.

    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}; } };
    And here is our file using it..
    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;
    Now the output.
    num is 4
    num is 4
    Can't locate object method "nomethod" via package "FunkyNum" at line 8.
    WOAH!!!! That isn't strict typing by any stretch of the measure. Now of course you could catch that error at runtime with a
    pre { ref $_[0] && $_[0]->isa("FunkyNum") };
    in that method implementation, but you can do that in perl anyway. Moreover, now it only works on refrences, thus you have to change your code and make it not use scalars.(so long plusequal(2) and hello plusequal(new FunkNum 2) )And it happens at runtime, not compiletime. So what have you gained? Well, A few things I can think of
    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.
    What have you lost?
    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.
    So there is the rundown of Contract. A great module, Conway rules. But it doesn't solve your "problem" of strict typing unless everything is an object and you isa everything as well. I suggest that you disabuse yourself of the notion that "strict typing" eq "good programs". In perl, you never have to say Template<T>.

    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!)


Re: Class::Struct, Class::Contract and type Safety
by baku (Scribe) on Feb 14, 2001 at 19:51 UTC

    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}; }

    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 :-)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://58356]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (2)
As of 2023-10-04 23:47 GMT
Find Nodes?
    Voting Booth?

    No recent polls found