Results 1 to 1 of 1

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

  1. #1
    thinBasic MVPs
    Join Date
    Oct 2012
    Rep Power

    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_Property GET

    but we do not have udt-subelements As Sub - that is bad and were required for
    UDT_Events (_create, _destroy, _onPropertyAdd, _onPropertyChange)
    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

    ional 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.


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

    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
    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_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?


    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
    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
    Last edited by ReneMiner; 14-09-2023 at 12:44.
    looking kind of abandoned

Similar Threads

  1. [Q]: Function f() PTR?
    By ReneMiner in forum thinBasic General
    Replies: 3
    Last Post: 18-07-2013, 20:29
  2. Wait function
    By peralta_mike in forum thinBasic General
    Replies: 4
    Last Post: 06-07-2010, 04:41
  3. Function pointers?
    By MouseTrap in forum thinBasic General
    Replies: 2
    Last Post: 18-02-2009, 21:35
  4. Function Address
    By peter in forum General
    Replies: 7
    Last Post: 29-10-2008, 22:35
  5. function returned value
    By sandyrepope in forum thinBasic General
    Replies: 4
    Last Post: 07-12-2007, 22:54

Members who have read this thread: 4

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts