Page 1 of 1

DeclareOverload

Posted: Sat Jul 06, 2013 10:34 pm
by luis
A poor man overloading implemented in a style that should follow PB philosophy and that should be easy to understand and implement.

Code: Select all

DeclareOverload
 Prototype.i Test (a.i, b.i) As Test_I()
 Prototype.f Test (a.f, b.f) As Test_F()
 Prototype.s Test (a.s, b.s) As Test_S()
EndDeclareOverload

Procedure.i Test_I (a.i, b.i)
 ProcedureReturn a + b
EndProcedure

Procedure.f Test_F (a.f, b.f)
 ProcedureReturn a + b
EndProcedure

Procedure.s Test_S (a$, b$)
 ProcedureReturn a$ + b$
EndProcedure


Debug Test (5, 6) ; result is the integer 11

Debug Test (1.2, 3.3) ; result is the float 4.5

Debug Test ("Hello", " World") ; result is the string "Hello World"
Or something like that :wink:

Re: DeclarePolymorph

Posted: Sat Jul 06, 2013 11:04 pm
by skywalk
I could use this for math and array libs...but probably not gonna happen :(

Re: DeclarePolymorph

Posted: Sat Jul 06, 2013 11:17 pm
by c4s
Oh yes, I would really like that e.g. in this situation. :o

Re: DeclarePolymorph

Posted: Sat Jul 06, 2013 11:18 pm
by luis
@skywalk

Eh, I don't know. I hope it will not be considered "confusing" for the beginners :)
But I don't see why, it's easy to understand because nothing is happening under the hood, it's not more complicated to use than a callback, and we have those.
I would use it for soooooo many things, it would be awesome.

Re: DeclarePolymorph

Posted: Sun Jul 07, 2013 2:18 am
by idle
using a macro you can kind of achieve it by testing the return values
but having a DeclarePolyMorphic would be very useful

Code: Select all

Procedure.i Test_I (a.i, b.i)
 ProcedureReturn a + b
EndProcedure

Procedure.f Test_F (a.f, b.f)
 ProcedureReturn a + b
EndProcedure

Procedure.s Test_S (a$, b$)
 ProcedureReturn a$ + b$
EndProcedure

Macro Test(r,a,b) 
    CompilerSelect TypeOf(r) 
      CompilerCase #PB_Integer
          r = Test_I (a,b)
      CompilerCase  #PB_Float
          r = Test_F (a, b)
         CompilerCase #PB_String   
          r = Test_S (a,b)
      CompilerEndSelect 
 EndMacro 
 
  
Define a.i,b.f,c.s
 
Test (a,5, 6) ; result is the integer 11
Debug a 
Test (b,1.2, 3.3) ; result is the float 4.5
Debug b 
Test (c,"Hello", " World") ; result is the string "Hello World"
Debug c

Re: DeclarePolymorph

Posted: Sun Jul 07, 2013 11:55 am
by luis
using a macro you can kind of achieve it by testing the return values


yes ... in this specific example.

In this specific case was possible because the return values were all different so you were able to select the macro to call using TypeOf.

TypeOf does not work with constants, and in this case it was usable since you had a var used to store the result. You could not use it to make selections based on the parameters, which can be literal constants.

So if we change the example above with a polymorphic proc returning always integer, and accepting different types of parameters, the workaround (because it's not really equivalent anyway, for example can't be used as part of an expression) above cannot be implemented.

Re: DeclarePolymorph

Posted: Mon Jul 08, 2013 12:27 am
by Danilo
Much simpler function overloading, automatically, without need for extra declaration:

Code: Select all

Procedure.i Test(a.i, b.i) ; internal compiler name signature: i_Test_i_i or i#Test#i#i
 ProcedureReturn a + b
EndProcedure

Procedure.f Test(a.f, b.f) ; internal compiler name signature: f_Test_f_f or f#Test#f#f
 ProcedureReturn a + b
EndProcedure

Procedure.s Test(a$, b$)   ; internal compiler name signature: s_Test_s_s or s#Test#s#s
 ProcedureReturn a$ + b$
EndProcedure


Debug Test (5, 6)              ; result is the integer 11            ( calls i#Test#i#i / i_Test_i_i )

Debug Test (1.2, 3.3)          ; result is the float 4.5             ( calls f#Test#f#f / f_Test_f_f )

Debug Test ("Hello", " World") ; result is the string "Hello World"  ( calls s#Test#s#s / s_Test_s_s )

Re: DeclarePolymorph

Posted: Mon Jul 08, 2013 10:43 am
by luis
danilo wrote:Much simpler function overloading, automatically, without need for extra declaration
I know. This is how you do it in other languages.

Using your way the compiler would need to cope with multiple procedures having the same name.

Something well against how PB works right now. I think it would bring *A LOT* of problems for Fred/Freak.

My proposal is the way it is because I tried to mimic the way PB tend to implement things.
The compiler does not need to be particularly smart, you manually specify what is linked to what, and most importantly you continue to have different procedures with different names.
A little longer to describe for the programmer, but giving the same advantages when he uses it.

So I proposed one I thought can have a little more chance to be accepted: there was some reasoning behind it :wink:
Anything more sophisticated would be perfectly fine with me obviously, *I* don't have anything against it.

Re: DeclarePolymorph

Posted: Mon Jul 08, 2013 10:56 am
by Danilo
luis wrote:Using my way, the compiler does not need to be particularly smart, you specify what is linked to what
I think it is the same.

Test(5, 6) becomes i_Test_i_i() or i#Test#i#i() or Test_I() - the compiler has to check the types and
call the corresponding procedure signature.
It is not different, the simple type checks have to be done anyway to determine which proc is called.
Shouldn't be that hard at all, the compiler has the type infos already. More important is to match
ambiguities like Test(a.b, b.a) to automatically cast to a defined function (for example, types b,a are converted to i,i)
or give an error if no proper auto-casting is available.

Re: DeclarePolymorph

Posted: Mon Jul 08, 2013 11:02 am
by luis
I understand how should work but I believe having multiple procs with the same name would be the problematic aspect for the compiler (for the language actually) as it is now.
Anyway it's up to the devs, they will read your proposal too and if they want to do all the extra work it's fine with me; certainly I'm not against your idea.
I think this would be a killer feature in any form, having to invoke different procedures with different names when they are exactly the same just because a param is of a different type it's really painful.

Obviously all this would be easier to implement if PB weren't doing any type conversion automatically. Having to explicitly cast everything only when really needed would eliminate any possible ambiguity and it will made easier to understand too.

Probably it will never happen, but it had to be requested. :)

BTW: you are right is overloading and not polymorphism, don't know what I was thinking, I changed the keywords to reflect that.

Re: DeclareOverload

Posted: Fri Feb 01, 2019 12:57 pm
by luis
A quinquennial bump should not create too much uproar.

Re: DeclareOverload

Posted: Wed Feb 13, 2019 1:34 am
by StarBootics
+1 for Procedure overloading.

Best regards
StarBootics