Request for polymorphism

[Agamemnus]

At a minimum, less typing.

And then the benefit is...? I still don't know.

Less typing in this way is **ALWAYS** a downside in my opinion. THIS IS WHY I don't program in C, C++, Java, etc.

Less typing = less readability. READABILITY is an important aspect of a programming language! Readability means people can actually understand what it does, without skipping one freaking character and misinterpreting the ENTIRE THING.



Call me an idiot, but I'm the type of person who won't notice the squared sign in sigma squared right away.

[stylin]

At a minimum, less typing.

Only a nice side-effect.

And then the benefit is...? I still don't know.

Less typing in this way is **ALWAYS** a downside in my opinion. THIS IS WHY I don't program in C, C++, Java, etc.

You probably shouldn't use qualifiers like "always" and "never"; they tend to leave a bad taste in people's mouths, especially in this case since frankly, it's wrong.

I'd like you to prove to me that you having to duplicate 10 functions by hand in BASIC is better sometimes, let alone better always, than C++, which, with templates, can do it in one.

It seems obvious to me that more typing, in the form of code duplication, is a breeding ground for error. I'm only human, just as I assume you are. If I have to rewrite 10 functions that only differ in the types that are passed to them I guarantee you I will make mistakes - at least 10 of them. Why not make it easy on myself and only write one, leaving the monotonous, error-prone work of code duplication for the compiler to sort out?

Let's say you have a stack container that holds integers. You mean to tell me that you'd rather copy the whole entire stack code to be able to use bytes, shorts, strings, zstrings, longs - not to mention pointers of all the aforementioned types ??? And if you decide to try C's approach and use void pointers, where has that got you? Thrown straight out of the land of type-safety, where bugs can exist that will take you weeks to track down, if you ever do.

I really just don't see the sense in your argument here.

Less typing = less readability. READABILITY is an important aspect of a programming language! Readability means people can actually understand what it does, without skipping one freaking character and misinterpreting the ENTIRE THING.

Readability is very important. But less typing != less readability inherently. I think you're hung up on obfuscation, which is not what generic programming is.

Call me an idiot, but I'm the type of person who won't notice the squared sign in sigma squared right away.

That's why we have compiler error messages.

Besides, as I said, not having to duplicate code is just a bi-product of the generic programming idiom. You don't use templates to reduce typing, you use them to make your programs more powerful, extensible, flexible, maintainable - and above all - SAFE.

[marzecTM]

i sense you are coming from the dark side stylin ( /me does darkside welcome move... ). i wonder, you having your background, why would you want to code with fb? or even better why would you want to introduce all the funky things from c++ to freebasic ( see your oo basic syntax above ).

on the argument on less typing is bad. i agree with stylin, couldn't have put it any better heh

[stylin]

i sense you are coming from the dark side stylin ( /me does darkside welcome move... ).

If by 'darkside' you mean ... C++, then yes, I'm familiar with it. (IMO, the darkside is everything C, but that's another thread) :-?

i wonder, you having your background, why would you want to code with fb? or even better why would you want to introduce all the funky things from c++ to freebasic ( see your oo basic syntax above ).

I grew up with the BASIC language, beginning on the C64. I haven't used BASIC in a long time, but I have good memories. It's just frustrating sometimes when I spend hours thinking about how to do something in BASIC that would take me minutes in C++ (plus or minus a few for debugging).

And hey, I figure if they're gonna implement object types and polymorphism, they might as well throw in templates - why not?

[Agamemnus]

stylin,

In this context, what I mean by "less typing" is some sort of trick that makes a program harder to read (at least for most people) and makes fewer characters. This is a subjective definition, so you cannot say I am wrong.

I still can't figure out any of these examples here, but perhaps I need to "learn more"...

[wallace]

I didn't know that I needed to include "overload" in the sub declareation.

Now that I think of it operator overloading might be nice too, for things like arrays and stuff.

[Jofers]

That is planned, but it will take a very long time.

[wallace]

I really don't see the need for it really. I mean most people would figure out how to use a sub, I mean:

inline operator = (array1() as integer, array2() as integer)
and
declare sub equals(array1() as integer, array2() as integer)

would have the same code and not be a hassle to implement.

[stylin]

I really don't see the need for it really. I mean most people would figure out how to use a sub, I mean:

inline operator = (array1() as integer, array2() as integer)
and
declare sub equals(array1() as integer, array2() as integer)

would have the same code and not be a hassle to implement.

You seem to be talking about global operators here. BASIC won't be complete without object classes, and then we can talk about the assignment operator.

Barring that, there's an interesting, and I think relavent, point to be made here: How is BASIC going to implement assignment and equality operators? I think it's going to be very hard if they don't want all code written thus far to crumble into dust.

The reason being that in BASIC, the assignment and equality operators are the same! In C++, these operators are expressed differently:

Code:

TYPE & operator = ( const TYPE & lhs, const TYPE & rh );   // assignment operator
bool operator == ( const TYPE & lhs, const TYPE & rhs );   // equality operator
   ...
TYPE object1, object2, object3;
   ...
object1 = object2 = object3;
if( object1 == object3 ) std::cout << "Everything is as it should be.";

BASIC doesn't have that, so operator overloading the equality/assignment operator is going to be tough:

Code:

'' functions for equality comparison and assignment
declare function is_equal( byref lhs as SOME_TYPE, byref rhs as SOME_TYPE ) as integer
declare function assign( byref lhs as SOME_TYPE, byref rhs as SOME_TYPE ) as SOME_TYPE
   ...
'' which operator means what? We can't determine that by return-type alone :(
declare function operator = ( byref lhs as SOME_TYPE, byref rhs as SOME_TYPE ) as integer
declare function operator = ( byref lhs as SOME_TYPE, byref rhs as SOME_TYPE ) as SOME_TYPE
   ...

dim as SOME_TYPE object1, object2, object3
   ...
'' assign and compare equality using functions (laborious, to say the least)
assign( object1, assign( object2, object3 ) )
if( is_equal( object1, object2 ) ) then print "Boy was that hard!"

'' assign and compare equality using global operator overloads (won't work: ambiguous)
object1 = object2 = object3
if( object1 = object2 ) then print "Unfortunely, we can't do this :("

Personally, I think they should change the equality operator to ==, or change the assignment operator to := ... or something.

Regardless, the whole point of operator overloading is that you don't need to explicitly call functions in an expression. See how much clearer the above code is when we use the operators themselves and not assignment/equality functions?

[Plasma]

If we change the equality operator to == we might as well add semicolons and call it C++.

I think you're missing the point of BASIC. It's supposed to be readable and easy for a beginning programmer to pick up. Not C++ without the braces and semicolons.