Overloaded Functions and Methods
BlitzMax Forums/BlitzMax Programming/Overloaded Functions and Methods
| ||
| I've searched the forums. I can't find a specific request, nor a specific refusal. I can find one comment from a user saying he thought they had been declared "never going to happen". Is that the case? Are they definitely not going to happen? I was going to post a feature request, but also had the suspicion I had read they weren't going to happen. Can't find any such statement now, but I may be looking in the wrong forum. So some clarification would be great. |
| ||
| I thought all the time Blitzmax supported overloading and 2 days ago I realized this too when trying to do it. It's a very useful thing to have so I'd like to know about this too... |
| ||
| There was some problem about the ambiguity of passing different types of numbers and the implicit casting that goes on there, and stuff like that. I'd still like to see some way for this to work, maybe with a special mode like strict mode for people who know what they're doing, but I think it's pretty unlikely at this stage. |
| ||
| Nothing recent, but there's a thread entitled "Overloaded functions" from two years ago. Mark's first reply (of his five posts) there is "This wont be added. While there are some good arguements for, there are enough against to make me anti it" and he shows some examples. |
| ||
| Thanks. Perhaps I was thinking of this older discussion, which would have been long before BlitzMax was close to completion. However, the points about automatic type casting still apply, I guess, so there are still problems to overcome. At the risk of going off topic in my own thread, I'm a little confused about what BlitzMax is and who it's aimed at. Despite promises that none of the new stuff would be forced on beginners, a lot of it is, and it is putting them off. And yet on the other hand it's still lacking a huge number of advanced features. It seems to fall between two stools. |
| ||
| ive thought alot about this lately and im wondering if mark is thinking too deep... i think a limited version of method overloading would be better than none at all. for example, have a limitation that overloads must have a different parameter count. this would solve having to deal with determining which overload is desired. most overloads ive had to work around have a different count anyway, and if you did have 2 with the same, just tack on a pad param with a default of null to make the count different. |
| ||
| Yep, I would be perfectly happy just to have Function and Method overloading where the number of parameters was different. As you say, you can easily pad it out as a workaround. |
| ||
| Function overloading can be very useful in certain cases ("double dispatch" off the top of my head.) I definitely think the language should support this. |
| ||
| However, the points about automatic type casting still apply, I guess, so there are still problems to overcome. It never applied. The solution is easy as pie. Make a rule that determines which should be invoked given certain circumstances, (for example, strings always win, since everything can be converted to a string and throw a compiler warning when an unclear choice (ie bad programming) presents itself.Our unit test framework (for instance) currently has a rediculous number of Assert Methods, with a very confusing interface, because we have to append the name of the Type taken as a parameter to the end of every function. It seems to fall between two stools. Jack of all trades, master of none? Never the less BlitzMAX is still in my opinion the hands down best language available, for nearly anything. Sure it lacks a few things (ad-hoc polymorphism being one, proper access modifiers being another and a decent Eclipse plug-in being absolutely essential), but it's still by far the language that produces the largest ammount of functional code, per unit of time.Personally tho', I don't see the "new stuff being forced on beginers" as being a problem, because it's abstracted from the way computers really work, it's actually easier than doing it the procedural way. Providing you don't go overboard. I guess seeing any language updates, that don't provide some form of advancement towards the 3D module, until said module has shipped is probably pushing it. |
| ||
| Hmm, I think the way that some language does it (c++?) is to encode the parameters into the name of the function. So when compiling doStuff(i:Int,f:Float) you get the symbol doStuff_Int_Float or something, because that is different from doStuff(s:String,d:Double), which would be doStuff_String_Double. The only limitation would be that you have to get the types exact. If you have doStuff(i:Int,f:Float), doStuff(2, 5.0) would work as it compiles down to doStuff_Int_Float. But say you did doStuff(999999999999, 5.0). That wouldn't work because it would compile down to doStuff_Long_Float, which isn't the same. That would solve the issue of which function to choose. For the other issues like the Base/Derived example, I think an arbitrary rule would have to be set such as always pick Base or something. |
| ||
| It never applied. The solution is easy as pie. Make a rule ... Well said FlameDuck. I'd be happy if overloading required an exact match with the parameter types. You explicitly cast things if necessary in the invocation. No arguments about potential confusion there. Even better if there is an algorithm to do some automatic casting to get a match. Like every other language that implements this you just have a sensible compatibility list like: int -> long, single, double long -> single, double single -> double And a rule for matching the parameter list to condidate method signatures to choose the best one. If there is no best one then that is a compile time 'ambiguity' problem so give an error message. Come on - Fix this. Please ! |
   |