I was wondering if there isn't a way to adding different operators for

<= opCmpLE Lesser Equal

< opCmpL Lesser

> opCmpG Greater

>= opCmpGE Greater Equal

== opEqual

!= opInequal

or is there a way of

asIObjectType::GetMethodByIndex() 

to differ between them being either of these?

When dumping the API it adds opEqual and opCmp and there is no difference for them, I am using it to export the documentation, I guess I could just in the case it finds opEqual or opCmp run fixed iterations for each of them.

so that I have

+=

+

instead of

opAddAssign

opAdd

Not really a huge problem, it was just a suggestion. : )

I meant there is no difference between opCmp and opEqual when dumping the API, but as I also said, no worries I will just iterate and export it twice over with different string values.

I can think of two potential applications of separate comparison operators. One is the case of types for which trichotomy does not hold, such as ones in which comparisons are to be based on float comparisons (where the relations between two values can be either less than, equal, greater than or unordered). In this case, a programmer may want to code operator overloads in such a way that, for unordered values, ==, <, >, <= and >= return false while != returns true. This isn't currently entirely possible, but probably could be accomplished without separate operator overloads, e.g. if opCmp was allowed to return a float instead of int (then it could return NaN in case of unordered comparisons). Speaking of which, however, I also recall that, even in primitive float types, comparisons between unordered values fail to return correct results in AngelScript. I even remember having observed strange behavior where const float NaN behaved differently in comparisons than non-const float NaN but I don't remember the details and I've been testing it a few releases ago so things might've changed.

The other scenario that comes to mind is when one wants to create lazy operators with use of functors, like it was done in Phoenix. In this case, all comparison operators would be expected to return a functor rather than a bool, effectively making any default implementation of part of the operators impossible. However, AngelScript is probably missing far more than just that in order to make those functors possible and useful; I'd predict huge difficulties in the template department for a start, with no such thing as C++'s std::function.

Dumping the API as in your test_dump, I am using that test to dump all exposed classes in C++ instead of having to write documentation wrappers around the register methods.

but the dumped code will write the operators and behaviors as

_beh(number

opEqual

opCmp

opAddAssign

once

for any other language these operators are written explicitly as

function name()
==
!=
<=
>=
+=

What I am doing is converting opAddAssign to += in the output file instead because they are universal through all languages

you would write

object.opAddAssign(input);

but

object += input;

as it is more readable. hence to document my exposed scripting objects,enums,behaviors I dump all C++ api inputs to different text files.

so for dumping opCmp

I would have to do

Write(replace(string,"opCmp",'<'))
Write(replace(string,"opCmp",'<='))
Write(replace(string,"opCmp",'>'))
Write(replace(string,"opCmp",'>='))

Ah yes, I absolutely agree something like Phoenix would be an overkill and not what a scripting language should aim to support, it just happened to be the only good usage of non-Boolean comparison operators I could recall. It's really nice to hear that lambda functions will become available too, I'm really looking forward to that.