One of the beauties of the original Traits paper was that its roles had
ways of specifying assertions of what criteria must be met by whatever
classes they were to be composed into.  Meanwhile, it's been mentioned
that roles and classes in P6 might look declarative in nature, but they
are in fact procedural.  

So why not allow a few assertions to be made in roles?  These would be
assertions which get run by the class when it composes the roles, and
returning false would raise an exception to the programmer, quite possibly
providing at compile-time some detailed information as to what he left out
of the class.  So instead of having to hunt through a bunch of code inside
a method to find that there's a reference to an attribute $.x, he'd get an
error message triggered by an assertion that the class must have an
attribute $.x.  

Or:

  role A {
    $::_ can x; # asserts that the class must provide a method called x
    method y () {
      # a whole bunch of code
      # a line that makes reference to $.x
      # a bunch of additional code
    }
  }
  
  class Foo {
    does A;
  };

This would produce a compile-time error "class Foo can't x as role A
requires" instead of a compile-time error "$.x undefined" or somesuch,
which is what you'd get without the "can" assertion.  The code would work
either way; the difference is in how much debugging is needed for a
programmer to find and correct his mistake.  

IMHO, code which serves no other purpose than to produce speedy and
intelligent error messages is still quite a valuable thing.  

=====
Jonathan "Dataweaver" Lang


        
                
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

Reply via email to