[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl5-porters
Subject:    Re: [ID 20010218.003] overload, +=, uninitialised value warnings
From:       Ilya Zakharevich <ilya () math ! ohio-state ! edu>
Date:       2001-02-28 21:13:34
[Download RAW message or body]

Here is my summary of the situation:

Alex Gough writes:
> >> This is something of a pain because it gives rise to spurious warnings
> >> which are hard to pin down, especially when the warning is reported in
> >> a .pm file.  The annoying thing here is that I cannot see a way to fix
> >> this within the overloading module, 

> > I would have thought defining a '+=' would have done the trick.

> No, perl seems to be turning  $undef += $obj  into
> $undef = $undef + $obj  which causes '+' to be called, where $undef is a 
> non special uninitialised variable, the following outputs:

So, there is weak spot in the current semantic of overloading.  The
idea of overloading is that the overloaded operations gets the *full*
information about its context.  There are two cases when this is is
not so in the current implementation:

 a) ++ and -- do not distinguish post- and pre-increment;

 b)   $non_object += $object;

    is converted to $non_object = $object->'+'($non_object, 1), which
    has the same arguments as when overloading

      $non_object + $object

Here is the chunk of the documentation:

     FALSE  the order of arguments is as in the current
            operation.

     TRUE   the arguments are reversed.

     undef  the current operation is an assignment variant (as in
            $a+=7), but the usual function is called instead.
            This additional information can be used to generate
            some optimizations.  Compare the section on Calling
            Conventions for Mutators.

As you see, there are 3 possible cases for this argument.  But there
are two possible bits of information to convey:

  1) whether the arguments are reversed;
  2) whether the assignment form was used;

So we need 4 different values of the third argument.  Here is the
proposal on the backward-compatible change of semantic:

     FALSE  the order of arguments is as in the current
            operation.

   Negative the arguments are reversed, and the actual operation
	    is an assignment variant, as in

	       $non_object -= $object

   Positive the arguments are reversed, the actual operation is not
	    an assignment variant.

     undef  the current operation is an assignment variant (as in
            $a+=7), with the first argument being an overloaded
            object, but the usual function is called instead.  This
            additional information can be used to generate some
            optimizations.  Compare the section on Calling Conventions
            for Mutators.

This is backward-compatible as far as documentation goes, and (I hope)
is backward-compatible with actual implementations too.

Please let me know if some actual implementation will misbehave with
this change. 

Hope this helps,
Ilya

P.S.  What about adding 'post++' and 'post--' (with fall-back to  to
      '++', '--' if needed) while doing this?

[prev in list] [next in list] [prev in thread] [next in thread]