Function Overload - yes we can - and why we need UDT-Subelement as SUB

Two things here: We have udt-subelements As Function - that is nice,
it allows to have
UDT_Methods
and
UDT_Property GET

but we do not have udt-subelements As Sub - that is bad and were required for
UDT_Events (_create, _destroy, _onPropertyAdd, _onPropertyChange)
and
UDT_Property SET

that has actually nothing to do with function overloading but were a step forward from udt into direction thinbasic-native script-classes
and module class extension by scripted procedures.

And Function overloading requires not a difference between sub and function but "function-indexing" through parameters and parameter-attributes as Optional, Byval, ByRef, parameters Datatype and Resulttype (use VOID instead of nothing at all for Subs)
Means all functions still are functions as they ever were but we hide a part of the name from the Users -

so they have the impression they can have unlimited functions with the same name that can even return different result-types
- without any major changes to the current internal handling

Small example

function differing from mandatory byREF down to byVAL parameters TYPE and the RESULT-TYPE

OPTional adds more functions with same basic name

Eyes on UCASE above...
example (incomplete, you should be able to fill the missing information to your mind how to detect a function duplicate when the parameters
match in types on equal positions. parameters names are useless here since they are not passed when calling a function.
It would need complete different ways to call a function alike some by a function provided parameter-table that must be used and filled by a caller - here were plenty of room for security & privacy also.

READY?

OK, there ya go!
time is running... tic tic tac tic tic tac

Code:

---

Function XY(byREF abc As LONG,OPTional ByVAL defghi as BYTE) As QUAD

 End Function
Function XY(ByRef abc As Long, Opt ByVal defghi As Double, Optional byVal RGB As String*3) As Long

End Function

---

Simply
for the upper function

Function_Name(User) = XY

becomes internal 2 function names with the same address to jump into

Function_Name(Core) = XY_REFLONGVALBYTEQUAD
Function_Name(Core) = XY_REFLONGQUAD
the lower function

Function_Name(User) = XY

becomes 4 function names
Function_Name(Core) = XY_REFLONGVALDOUBLEVALSTRING3LONG
Function_Name(Core) = XY_REFLONGVALDOUBLELONG
Function_Name(Core) = XY_REFLONGVALSTRING3LONG
Function_Name(Core) = XY_REFLONGLONG


And all of those are "Function XY" for the users eye

It should not be difficult for thincore to differ between those functions and it could need an impossible to use char-combination as "|!|" to tell thincore the difference of core-function names (here "XY|!|REFLONG...") and users function-Names ("XY")

For the users the part before underscore appears to be the name while the name in reality is all but parameters names.
Of course this excludes 2 times the same parameter-pattern - you can not have 2 times a function that has just 1 byte parameter byval
or one that has 2 equal type parameters byref. Parenthesis (for array parameters) would also be part of function_Name(Core) as
"()" = DYNAR,
"(ANY)" = VDCAR
"(1 To 23,255)" =FIXAR_00000001_00000017_00000001_000000FF_00000000_00000000
(underscores only for visual support to readers)

Even the result-type of obviously the same function can be a different one


And how could that be?

Does this seed any idea to your minds?

EDIT

For things as Function_GetPtr still to work it requires a fixed rule how to build internal functions names,
e.g. "parameter-attribute Byval" becomes "VAL",
datatypes must use special ALIAS ("INT32","CHAR16") or must use built-In typenames ("LONG", "EXT"),
to a Sub (no result-parameter) the letters "SUB" or "VOID" have to be appended
etc.
such rules must be clarified then
Call_ifExists "XY"(3, abc) can use the same way to build a the complete name as usual function calls
function_GetPtr("" & sName) for the average -up to now- usage
function_GetPtr("xy", "REFLONGVALBYTEQUAD") with an optional new parameter for the hardcore-coders and low level hackers is not a problem