Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote:
However, the CGI/CGI::Simple example I posted earlier doesn't fulfill
this.  CGI::Simple offers a subset of CGI.pm's functionality and it's
guaranteed to be identical (it doesn't have HTML generation
functionality and the procedural/OO interfaces are clearly split).  I
can usually use the latter in place of the former, but since semantic
meaning isn't attached, restricting me to roles doesn't work. Requiring others to use roles in this case is also too restrictive.



My take on it: If a Perl 6 program declares the function without typing the parameter, you can pass anything without complaint, like with Perl 5, Smalltalk, etc.

If the function were declared to take a CGI object, and you had a CGI::Simple object, and they were not updated to explain the relationship, you would get a type error.

Rather than needing to delete the type from the parameter, or go ahead and re-factor the classes, it is important that it be easy enough to proceed forward in the current situation and get the benefits of typing that have been added so far, without making the rest of the code useless. So, you explicitly say at the point of the call to "make it fit", thus getting the old (run-time method checking) effects without having to back out the type info added thus far.

      sub foo (CGI) { ... }    # you want to use
      my CGI::Simple $x .= new;
      foo($x);    # nope, compile-time error
      foo(shoehorn $x);  # OK, pretty much the same as if you took
# the type off foo's parameter declaration

A next step would be to declare once that it is OK to use CGI::Simple where a CGI is wanted, shoehorning automatically, within the scope of said instruction.
      I declare, CGI::Simple is an allomorph to CGI.
      ...
      foo($x);   # OK.

And a better later step in the evolution is for the author of CGI::Simple to explain the overlap in more detail, without having to touch the CGI class (someone else's code), that will improve upon the checking from the default match-them-all-by-name. Shoehorn sees what is missing, and adds adapters with range checks around changed parameter types, but assumes that bark==bark. The custom explanation can relax the checking, add little adapter wedges, and note when the method should not be considered a match.

Also, if you further update foo's declaration to

     sub foo (CGI ::T $p) { ... }

then you can get errors sooner rather than when the missing method is called on $p, and code within foo can incrementally change its own use of CGI to T to further the effect.

That is, there is always an easy way forward.

--John

Reply via email to