On Fri Jul 10 14:20:06 2015, coke wrote:
> On Sat Jun 13 14:37:03 2015, ronaldxs wrote:
> > On Sat May 11 13:48:34 2013, FROGGS.de wrote:
> > > TimToady: yes, comparisons should return failure, not automatically
> > > thrown an exception.
> >
> > It throws an appropriate exception now.  I think if a qualified
> > person
> > looked at this ticket they could close it.
> >
> > Ron
> 
> Note that the sample code needs to be formatted thusly:
> 
> > my Int $x; if $x <=0 { say 'cmp OK' }
> Invocant requires a 'Int' instance, but a type object was passed.  Did
> you forget a .new?
> 
> This seems to jibe with expectations. Added tests to S03-
> operators/misc.t .... but a nearly identical test for Str doesn't fail
> the same way. Test todo'd, needs some work.

As far as I understand, the current implementation does not match the design
docs. Even for the case tested in S03-operators/misc.t the Exception is thrown
immediately -- instead of being returned as a Failure.

My -- maybe naive -- idea would be to add appropriate multi candidates for
all the comparison operators. For example for infix:<gt>:

  diff --git a/src/core/Stringy.pm b/src/core/Stringy.pm
  index f8e2279..3364b6f 100644
  --- a/src/core/Stringy.pm
  +++ b/src/core/Stringy.pm
  @@ -47,7 +47,13 @@ multi sub infix:<le>(\a, \b)       { a.Stringy le 
b.Stringy }
 
   proto sub infix:<gt>(Mu $?, Mu $?) is pure { * }
   multi sub infix:<gt>($x?)          { Bool::True }
  -multi sub infix:<gt>(\a, \b)       { a.Stringy gt b.Stringy }
  +multi sub infix:<gt>(Mu:U, \a) {
  +    Failure.new(X::AdHoc.new(:payload("failure 'cuz 1st argument of 
comparison is undefined")))
  +}
  +multi sub infix:<gt>(Mu:D \a, Mu:U) {
  +    Failure.new(X::AdHoc.new(:payload("failure 'cuz 2nd argument of 
comparison is undefined")))
  +}
  +multi sub infix:<gt>(Mu:D \a, Mu:D \b)       { a.Stringy gt b.Stringy }
   
   proto sub infix:<ge>(Mu $?, Mu $?) is pure { * }
   multi sub infix:<ge>($x?)          { Bool::True }

Maybe someone qualified can comment on this idea? I'd be willing to work on the
eventual implementation.

Christian

Reply via email to