StandBySystem
Re: StandBySystem
Let's focus to the polymorphism. It is accurate anymore.
Re: StandBySystem
How could we consider polymorphism with the current pureBasic syntax?
Through a procedure with only one argument, it appears simple : we could create the same quantity of procedures as the quantity of variable types we would want to code.
But such a rule causes a big number of procedures, if we have more than one argument :If we had, in example, a basic procedure, containing 4 arguments, and if we consider 3 types per argument, we would have to provide 12 specific procedures to the compiler.
I imagine a case switching pre-process. What do you think about this ?
ps: blub... blub... in Mississippi...
Through a procedure with only one argument, it appears simple : we could create the same quantity of procedures as the quantity of variable types we would want to code.
But such a rule causes a big number of procedures, if we have more than one argument :
Code: Select all
args : quantity of procedures
1 : x
2 : x * y
3 : x * y * z
4 : x * y * z * t
etc...
I imagine a case switching pre-process. What do you think about this ?
ps: blub... blub... in Mississippi...
Re: StandBySystem
Let's take an exemple...
Code: Select all
Structure Window
pName.S[6]
*p[6]
EndStructure
Procedure windowOpen0(T.s, f = #PB_Window_Borderless)
w = DesktopUnscaled(DesktopWidth(0) )
h = DesktopUnscaled(DesktopHeight(0) )
ProcedureReturn OpenWindow(#PB_Any, 0, 0, w, h, T, f ! #PB_Window_ScreenCentered)
EndProcedure
Procedure windowOpen1(Id, T.s, f = #PB_Window_Borderless)
w = DesktopUnscaled(DesktopWidth(0) )
h = DesktopUnscaled(DesktopHeight(0) )
ProcedureReturn OpenWindow(Id, 0, 0, w, h, T, f ! #PB_Window_ScreenCentered)
EndProcedure
Procedure windowOpen2(w, h, T.s, f = #PB_Window_Borderless)
ProcedureReturn OpenWindow(PB_Any, 0, 0, w, h, T, f ! #PB_Window_ScreenCentered)
EndProcedure
Procedure windowOpen3(Id, w, h, T.s, f = #PB_Window_Borderless)
ProcedureReturn OpenWindow(Id, 0, 0, w, h, T, f ! #PB_Window_ScreenCentered)
EndProcedure
Procedure windowOpen4(x, y, w, h, T.s, f = #PB_Window_Borderless)
ProcedureReturn OpenWindow(#PB_Any, x, y, w, h, T, f)
EndProcedure
Procedure windowOpen5(Id, x, y, w, h, T.s, f = #PB_Window_Borderless)
ProcedureReturn OpenWindow(Id, x, y, w, h, T, f)
EndProcedure
Macro windowNew(index =)
Define *win#index.Window = AllocateStructure(Window)
With *win#index
\p[0] = @openWindow0()
\p[1] = @openWindow1()
\p[2] = @openWindow2()
\p[3] = @openWindow3()
\p[4] = @openWindow4()
\p[5] = @openWindow5()
EndWith
EndMacro
Re: StandBySystem
So, with such a small source code, it is easier to imagine a pre-processing tool to apply polymorphism. The minimum codable concerns the native types : strings, integers and "reals".
Really, the difficulty is that a routine could detect which type is contained in an argument area between brackets :But, this routine cannot forsee which type exactly.
0.001 is it a double or a float ?
23 is it a long or a quad ? Plus, is it an integer or a "real" ?
I remember gwbasic/quickbasic/turbobasic forces the user to add a dot to inform the interpreter/compiler to consider it is a floating point number.This above causes a syntax error.
I think this detail is the only one the coder have to learn to allow the polymorphism on pureBasic : do not forget the dots on "real" numbers.
So, Rinzwind, my question is simple :
for a management of the lists whatever the type of the elements used, are you ready
* not to forget a "dot zero" to inform the pre-processor, that the immediate value is not an integer, but a floating point value ?
* to decide to work only on 32 bits, or only on 64 bits (being seen that the pre-processor cannot find a specific bit range - 8, 16, 32, 64 or 80 bits - from an immediate readable value) ?
If yes, I do not think to be the only person able to give a very small code, which nests itself in the code of this subject and allows you to dispose polymorphism.
Really, the difficulty is that a routine could detect which type is contained in an argument area between brackets :
Code: Select all
myProc(0.001) ; "real"
myProc(23) ; "integer"
myProc("hello") ; "string"
0.001 is it a double or a float ?
23 is it a long or a quad ? Plus, is it an integer or a "real" ?
I remember gwbasic/quickbasic/turbobasic forces the user to add a dot to inform the interpreter/compiler to consider it is a floating point number.
Code: Select all
x = 4.
Code: Select all
x = 4.0 ; terminal detail to allow polymorphism
Code: Select all
What does I read ? (direct datas)
- string -> search string argument
- number -> does a dot exist ?
* yes -> search a "double" argument
* no -> search a quad argument
Replace the "polymorphic" call
with the specific call.
for a management of the lists whatever the type of the elements used, are you ready
* not to forget a "dot zero" to inform the pre-processor, that the immediate value is not an integer, but a floating point value ?
* to decide to work only on 32 bits, or only on 64 bits (being seen that the pre-processor cannot find a specific bit range - 8, 16, 32, 64 or 80 bits - from an immediate readable value) ?
If yes, I do not think to be the only person able to give a very small code, which nests itself in the code of this subject and allows you to dispose polymorphism.