Koriolis,
You might be right about b) being a result of a) but either way many pains in BlitzMax would be solved by allowing method overloading.
I struggle to think of a non OO language that provides method overloading nor one apart from BlitzMax that is OO and fails to provide it. You must have some examples in mind ?
Seems to me that objects (contain data and code), inheritence (one thing is a more specialised version of another with possible new data and code) and polymorphism (an object reference can be the base type or something derived from it) concepts follow each other naturally. This is surely the heart of OO.
The desire for overloading arises directly as a productivity requirement from inheritence. Even better if it is supported in the IDE then you get all of the variations of a method at your fingertips.
I just don't agree that choosing a method among overloaded alternatives leads to too much of a mess. Lots of mainstream languages do it (C++, Java, C#, Visual Basic). Lots of people have no problem with it and more to the point would complain bitterly if it was taken away.
And if it is an issue then do what I said. Require an exact type match for each parameter so there is no possible ambiguity. This may require explicit casting but so be it.
I agree with wanting access restrictions. You'll notice that in my 'ideal' last example it is a true constructor method rather than a factory function. Even better if you could then hide the default constructor like:
private Method New()
So that it cannot be invoked.
You might be right about b) being a result of a) but either way many pains in BlitzMax would be solved by allowing method overloading.
I struggle to think of a non OO language that provides method overloading nor one apart from BlitzMax that is OO and fails to provide it. You must have some examples in mind ?
Seems to me that objects (contain data and code), inheritence (one thing is a more specialised version of another with possible new data and code) and polymorphism (an object reference can be the base type or something derived from it) concepts follow each other naturally. This is surely the heart of OO.
The desire for overloading arises directly as a productivity requirement from inheritence. Even better if it is supported in the IDE then you get all of the variations of a method at your fingertips.
I just don't agree that choosing a method among overloaded alternatives leads to too much of a mess. Lots of mainstream languages do it (C++, Java, C#, Visual Basic). Lots of people have no problem with it and more to the point would complain bitterly if it was taken away.
And if it is an issue then do what I said. Require an exact type match for each parameter so there is no possible ambiguity. This may require explicit casting but so be it.
I agree with wanting access restrictions. You'll notice that in my 'ideal' last example it is a true constructor method rather than a factory function. Even better if you could then hide the default constructor like:
private Method New()
So that it cannot be invoked.