> ** remove class equals (too many equals)

This somewhat obscure point is probably the existence of a whole bunch
of x [op]= op-codes (+=, -=, &=, %= etc)

If so I have now removed them.

This turned out to be sort of interesting, actually, since +=, -= and
friends did not previously type-check the assignment, only the call to
the actual operator.

That is, a += 10 would check that (a+10) did not generate an error,
but not that it could be assigned to a. Especially with strict types
enabled this is a rather large change.

Take, as an example, gmp.mpz objects (and all other objects overloading
operators) since (object(*) + integer) type-checks to 'mixed'. The same
is true for the other operators.

I "solved" this for now by adding automatic softcasts to the type to
be assigned, which means that it again only checks that the operation
can be done validly, not that the assignment will always work.

So, given "Gmp.mpz a":
|  a += 10;

is now equivalent to
|  a = [object(Gmp.mpz)](a+10);

On a somewhat related note X[*] = x[*] op <something> was sort of broken as
well, it only worked for the short form assignments (x[*] += 10 etc).

I have partially fixed this now.

Previously it always converted the code to

|  x = x[*] op <something>

This works, in so far as x gets the new value. But it gives incorrect
(semantically, at least) results for this case:

|  array x = ..;
|  array y = x;
|  x[*] += 10;
|  /* now x would not be equal to y */

I have fixed this, but auto-map as lvalue (on the left side of
assignments) still has at least two issues:

|  x[*] = RHS (not an automap)

This will currently just break run time with 'Source is not an
array'. (Unless RHS happens to be an array with the same size as the
left array, then you will get unexpected results). It should simply
assign all elements in the array to RHS.

The other broken thing is multi-level automap assignments.

As an example:

|  a[*][*] += 10;

This will currently work, but the expression is basically converted to

|  a[*] = (a[*][*]+10)[*];

Which might be closer to what you wanted, but not quite perfect. :)

-- 
Per Hedbor
  • Development... Peter Bortas
    • Re: De... Arne Goedeke
    • Re: De... H. William Welliver III
      • Re... Danesh Daroui
      • Re... Arne Goedeke
        • ... H. William Welliver III
    • Develo... Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum
      • De... Per Hedbor () @ Pike (-) developers forum
    • Develo... Per Hedbor () @ Pike (-) developers forum
      • De... Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum
    • Re: De... Peter Bortas
      • Re... Per Hedbor () @ Pike (-) developers forum
        • ... Peter Bortas @ Pike developers forum
    • Re: De... Arne Goedeke
      • Re... Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum
        • ... Per Hedbor () @ Pike (-) developers forum
          • ... Arne Goedeke
      • Re... Arne Goedeke

Reply via email to