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?

The opCmp operator overload is already able to do all these with a single method.

Why do you want/need to have separate methods for each comparison operator?

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'm not sure what you mean with that there is no difference between them.

opEqual is used for == and !=

opCmp is used for <, >, <=, >=, and can also be used for == and != if opEqual is not available

The reason for the two to exist, is that for some types it doesn't make sense to have a relative comparison, i.e. they can only be equal or not equal. In this case the programmer would provide the opEqual method. If relative comparison makes sense the programmer would provide the opCmp method instead.

There is no need to provide both opCmp and opEqual in the same class.

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.

Zervoxe:

I still don't quite understand what you mean. What exactly do you mean with 'dumping the API'? And why isn't the difference in the function name evident when you dump the API?

Ser Ementaler:

I admit that NaN is probably not properly treated in AngelScript. It's just not something that I'm used to think about. I'll take note of that to check what needs to be improved.

Something like Phoenix is not something I aspire to support in AngelScript. It's way overkill for a scripting library in my opinion. Though, should it be possible to support it using existing functionality then that would be quite cool indeed. Functors is already possible and lambda functions will be implemented in the near future.

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.

Zervoxe:

Thanks. I finally understand what you're actually doing.

Well, since there is not a one-to-one mapping of opEquals and opCmp to the operators you'll need to add a bit more intelligence on the dumper. Something like this:

bool hasEqualityOp = false, hasRelativeOp = false;

if( strcmp(func->GetName(), "opCmp" ) == 0 ) // opCmp can be used for <, >, <=, >=, ==, !=

hasEqualityOp = hasRelativeOp = true;

else if( strcmp(func->GetName(), "opEquals" ) == 0 ) // opEquals can be used for ==, !=

hasEqualityOp = true;

if( hasEqualityOp )

{

Write('==');

Write('!=');

}

if( hasRelativeOp )

{

Write('<');

Write('>');

Write('<=');

Write('>=');

}