Waldek Hebisch wrote:
Basically, the whole operator overloading is a big kludge. I'd have liked to throw it all out, unfortunately there are some who need it ...
Someday it should be reimplemented, but currently it's not very urgent to me.
AFAIKS the current implementation is against the standard spirit.
AFAIK, the only standard (more or less) that has operator overloading is PXSC. I don't know it in detail. If someone here happens to know about it, please let us know ...
Namely, according to the standard declaration:
type typea = typeb;
merely introduces new name for `typeb'. And in all other places what matters is the type. To obey this spirit operators should use types, which will eliminate the whole quadratic seach completely.
Yes, that's my idea to reimplement it. There are some questions left, though:
- Should exact matching or only assignment compatibility be required (for value parameters)? The latter would seem logical to me.
- What if several operators match, should this be an error? (If so, it would not be possible to, e.g., define the same operator for Integer and LongInt. If not, it might be difficult to specify exactly which operator is used.)
- What if a user-defined operator conflicts with a built-in one? Should this be an error, or should the user-defined one always take precedence?
- ...
I think that type and operator handling can be fixed with quite moderate effort. Of course, that would break users of old semantic, who use alternate type name to trigger different operator :(.
Is there anybody here who requires this? (Just at attempt ... ;-)
I think it can always be worked around by creating a really new type (e.g., a record with one field), which would seem cleaner to me, too.
Frank