[fpc-pascal] Custom operators for non-record types

[JC Chu]

isbinaryoperatoroverloadable() is called once.  It first calls
internal_check() with the default (LHS, RHS) order.  internal_check()
accepts or rejects the pair only if it recognizes the pair.  Only if
(LHS, RHS) is not recognized, will internal_check() be called again
with the order reversed.  If neither (LHS, RHS) nor (RHS, LHS) is
recognized, isbinaryoperatoroverloadable() defaults to False.
(Besides, commutativity is a semantic property which relies on the
user implementation and cannot be deduced at compile time.)

Rejection rules are used to prevent conflicts with the default
interpretation.  The original implementation, however, rejects
overloads based solely on the operand type combination, not taking
into consideration the operator being used.  For the
string-as-the-first-operand case, this resulted in, say, * as a
function on (string, PChar) being rejected, which is legal.  What I
did with it is restrict the operand to +, =, <>, <, <=, >, and >=
(and, of course, removing the limits on the second operand being an
enumeration).

For some operators, only one-sided protection is necessary.  For
example, IN must not be overloaded as a function on (<enumeration>,
<set>).

For some operators, the set of accepted operand type pairs should be
symmetric, and thus so should its complement, the set of rejected
pairs.  If acceptance and rejection rules are inconsistent, rejection
becomes sensitive to the order of operands.  For example, I didn’t
change pointer-as-the-first-operand case to allow for (PChar, string)
overloads, so * as a function on (PChar, string), despite legal, still
gets rejected.

That is to say, the rules in internal_check() are not yet exhaustive.


On Tue, Jul 3, 2012 at 3:35 AM, Sven Barth <pascaldragon at googlemail.com> wrote:
> Am 02.07.2012 16:51 schrieb "JC Chu" <jcchu at acm.org>:
>
>
>> ◦  Restrictions on the string-as-the-first-operand case have been relaxed.
>
> I don't know whether you realized that already, but the
> isbinaryoperatoroverloadable function is called twice: once with the order
> given by the user and once with the order reversed as at least regarding the
> possibility of overloading the binary operators are commutative. So the
> checks for the first operand being a string indirectly also apply to the
> right one being a string.
>
> Regards,
> Sven
>
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal



-- 
Best regards,
JC Chu