Quote:
Originally posted by gannon
hehe why don't you combine operator overloading and multi init function.
Operator overloading isn't the same thing as function overloading. Function overloading would be like this:
int MonsterNew(string stat_file) {
// Load monster stats from a file
}
int MonsterNew(int MaxHP, int Strength, int Defense) {
// Use the supplied values for the monster stats
}
which is something Verge just won't allow.
Operator overloading is where you write special functions to handle cases where you use classes with the builtin operators, like +, -, * and so on. Like this:
Class:StatBonus
Field:StatID:byte
Field:BonusAmount:sword
Operator:StatBonus += StatBonus
if($first.StatID$ != $second.StatID$) {
Log('Can only add stats with the same StatID!');
return;
}
$first.BonusAmount$ += $second.BonusAmount$;
EndOperator
Operator:StatBonus += int
$first.BonusAmount$ += second;
EndOperator
With something like that, you could write code like this:
$weapon.StatBonus$ += weapon.RuneBonus$;
and have it add whatever bonus the weapon's runeBonus field (which is of type StatBonus) to the weapon's bonus.
Compare with this code that does the same thing without operator overloading:
int runeType = $weapon.RuneBonus.StatID$;
int statType = $weapon.StatBonus.StatID$;
if(runeType != statType) {
Log('Can only add stats with the same StatID!');
return;
}
$weapon.StatBonus.BonusAmount$ += weapon.RuneBonus.BonusAmount$;
Which makes things a lot more concise. I think I may end up implementing arbitrary operators as well, so you can come up with more meaningful relationships than '+', '-', '*', etc. That's something I've always wanted for C++. So you could do, like:
Rectangle r1,r2,r3;
// Do stuff with r1 and r2
r3 = r1 intersect r2;
// r3 is now equal to the overlap between r1 and r2
You'd have to be very careful about using that feature, since the parser could get confused if you're unlucky. But I expect to be able to find the types of all typed locals and parameters at compile time, and only applying the overloaded operations that actually exist, so the chances of you accidentally (for example) writing a string that has a valid operation in the middle of it that gets expanded are slim. And if you come up with some kind of convention for naming operators and stick to it then your chances of having your code survive are a lot better.
Yeah, I think I'm going to have to break the old style Code blocks in order to make operator overloading work, and after that example I'm more convinced than I was before that it's a good idea. ;P Shouldn't be too much trouble to fix up old code...the old style field references should still work, and the only change I anticipate being needed for the Code blocks is to put the function header on the first line, as InheritCode blocks already do.
