Danilo wrote:Without that check, it wouldn‘t be possible to catch any errors when converting from number types to strings. You could use numbers everywhere and if a parameter is of type string, the number would automatically be converted to a string. It may not always be what you want.
Code: Select all
LoadFont(1,2,3,4)
SetWindowTitle(0,1)
OpenWindow(#PB_Any, 0,0,800,600,0) ; No window title?
StringGadget(1, 0, 0, 100, 20, #PB_String_Numeric)
ButtonGadget(2, 0, 40, 100, 20, #PB_Button_Toggle) ; Where is the button text?
That's not quite right Danilo, this is not the way an eval system should work. If done correctly, each parameter is resolved individually, and this is
completely independent of what comes before this parameter, what comes after this parameter and
what data type is expected for this parameter. So no parameter is automatically converted to a string if no string is involved in the subterm of the parameter. Each of the functions shown by you would immediately end in an compilation error.
Danilo wrote:Code: Select all
result.s
result = 1 + 2 ; results in „12“
Same here. If done correctly, the result would be a string with the value "3". The assignment operator has a very low priority and so the rhs-term is resolved first whereby it
doesn't matter what kind of datatype the result variable is. Only when the rhs term is completely resolved the result is converted into the data type of the target variable and this result is assigned.
I don't want to say that it would be useful to integrate the functions suggested by FlatEarth into Pb this way (I'm not entirely sure about this myself), but it would be possible in any case. Additionally it should be mentioned that the evaluation functions of Pb, let's say it friendly, are very, very special and make many things much more complicated than in other programming languages.